最近我一直在努力改进/摆脱用于Web开发的标准MVC设置，我认为现在是时候将我的想法投射到StackOverflow了。
一般流程与引导程序创建初始对象的流程相同。不同之处在于它们保存在ServiceManager中。
然后，它不是分派控制器，而是加载视图。
然后视图调用命令和查询。命令表示通常与表单相关的功能（通常更新数据库行），而查询通常是ModelPeers。当它们被创建时（通过ServiceManager），它们将ServiceManager传递给它们，从而消除了对许多可能复杂的依赖注入的需要。
模型本身只会在一行上创建/更新/删除。
所以视图看起来像：
ListUsers.php
<?php $users = $this->ServiceManager->get('Query\User')->getNewestUsers(10); ?>
<?php foreach($users as $user): ?>
....
<?php endforeach; ?>
UpdateUser.php
<?php $this->ServiceManager->get('Command\User')->update(); ?>
<form>...</form>
我知道有一些违规行为，但它似乎比一堆控制器更像是ViewVariableSetter比任何东西更清晰。
它还使所有功能都更加可测试，因为所有功能都封装在命令和查询中，远离大型控制器。从技术上讲，我可以拥有一个控制器或ViewVariableSetter，但似乎它会添加更多的代码并且收效甚微。
我们将不胜感激，如果我能澄清一切，请告诉我。
答案 0 :(得分：3)
一旦将另一个开发人员添加到项目中以及项目变得越来越大，您将感觉 没什么好处。你会感谢你将视图与控制器和模型分开。
答案 1 :(得分：3)
如果你不喜欢MVC，你可以看看它的兄弟姐妹MVP（Model-View-Presenter），PM（Presentation Model）和MVVM（Model-View-ViewModel）。
事实上，你所描述的可能是PM，我不确定。
答案 2 :(得分：1)
这里有一个好的开始：将可重用/模块化代码称为来自控制器，而不是giganto单片控制器。
我的观点：也许问题不在于“MVC”，而是关于“V”（观点）的当前教条。当前的教条似乎是视图必须是一个（HTML）模板，其中代码必须编织成“对象艺术”。有人可能会说，对于许多应用来说，这只是制作工作。
也许我们需要更好/替代的“视图”技术：在设置CRUD编辑任务时，与营销信息亭（应该是艺术品）相反，我们制作API使用像浏览器中的javascript（或类似java AWT）的“DOM”模型生成表单和其他UI元素？只是一个想法。
回应评论：
“......我想避免让一个只将东西传递给视图的类......”
首先，当最小工作量时，应该可以使这个代码最少。例如，我喜欢“Rails”如何自动将应用程序的某个“区域”内的请求路由到一个类中，将请求映射到单个函数/处理程序。我已经在java代码中模拟了这种行为，以使响应更加简洁。
其次，这种“将信息传递给视图”只是“计算和存储，沿着简单步骤的管道传递数据”的特定实例。它使代码更易于理解和维护。我不是一个硬核“功能编程”的粉丝，但是能够（轻松地）理解一段代码中的数据流有一些东西可以说。作为附带的好处，它经常（不直观地，似乎）使代码实际运行得更快。之前我曾经大肆宣传“地方”，所以我不会在这里重复一遍。
答案 3 :(得分：0)
您将如何调整视图以适应不同的格式？例如html响应，json响应等。
答案 4 :(得分：0)
MVC对网络来说有点奇怪。大多数情况下，您并不需要视图和控制器之间的分离。另一方面，由于url充当应用程序状态，因此两者之间需要一定程度的互操作性。这导致两种情况之一;要么你只是部分分离，要么你得到很多复杂性。两者都不是非常有益。
我会说大多数框架选择轻松的分离。 Rails及其php克隆通常遵循此策略。就个人而言，我并没有真正看到这一点。双层（例如模型/表示）设计可以很好地适用于大多数应用程序。
对于使用行业标准，有一些事情要说 - 不管怎么说 - 只是因为它是一个标准。如果你自己开发自己的架构，其他开发人员将很难搞清楚它。你不应该低估有多少工作可以做到这样的事情。