“纯粹的”MVC实现有用吗？
我在一家提供定制“CRM”软件的公司工作。 我们目前正在重新设计/重新开发该软件，希望它看起来更现代，更容易为未来的客户开发和定制。 目前，定制每个新应用程序需要很长时间。
可以假设它花费这么长时间的原因是因为“视图”层中存在的业务逻辑量。 在某种程度上，我可以保证这是真的，但症状并不总能可靠地指出原因。 有一个建议是，如果我们只是将业务逻辑移动到控制器层并使用纯视图（我们使用java J2EE和struts），就像实现struts标签而不是调用bean层并在jsp上迭代对象 – 等等。
在我开始倡导之前，我们继续这样做，我想要了解其他人的想法。 MVC的“纯粹”实现（特别强调解耦控制器和视图）是否提供了更清晰，更易于开发和更改的代码库？
感谢大家的投入 – 这有很多帮助
您的目标应该是将您的业务逻辑放在一个地方。 根据我的经验，如果你能做到这一点，你的代码库将更容易开发，维护和更改。
模型 – 视图 – 控制器是达到这一点的一种方式，尽管在经典MVC中， 业务逻辑在（域）模型中，而应用程序逻辑在控制器中。
应用程序逻辑 ：如果用户的下一个检查日期在一周内（或过期），则显示“计划检查”屏幕，否则显示“检查历史记录”屏幕。
业务逻辑 ：以前检查失败的餐馆需要每六个月检查一次，每年必须检查海鲜餐馆，所有其他餐馆必须每两年检查一次。 鉴于这家餐厅的最后一次检查，他们的下次检查何时到期？
解耦始终如此。 无论如何，MVC与否，系统中的耦合越少，维护和更改就越容易。 MVC只是Web的良好模式，简化了解耦，就是这样。
MVC建议智能被适当地隔离。这意味着，视图和模型会有点愚蠢，控制器是真正聪明的人。 这意味着我们可以以流畅的方式创建修改愚蠢的家伙和聪明人。 当需求/代码修复有效开启时，这些好处将大大增加。 增加的抽象是一种痛苦，直到人们掌握所使用的模式。 这是服务器端的MVC。 客户端代码上的MVC怎么样？
有时，视图模型具有内置于其中的不同智能并且被编码到业务代表中是非常正确的。 但是，更好的方法是使用自定义标签。 关于jsp页面最烦人的事情发生在他们将javascript与代码混淆时，这个智能代码实际上试图操纵DOM并在静态jsp代码中产生无法匹配的标签。
因为你有从头开始的奢侈品。 如果每个人都使用不引人注意的javascript（一种与java不同的语言，比我在生产代码中看到的那种语言更容易）和自定义标签（并不那么困难），那么生活会更简单。 另一个痛点是没有符合W3C标准的html / css。 如果你是他们的话，浏览器问题会带来巨大的麻烦。
PS：长期咆哮的应用:)
有人这样说：
“计算机科学中的任何问题都可以通过另一层间接解决”
但我不记得谁是这句话的作者。 有人知道吗？
我在一家非常严格遵循MVC的公司工作，我们已经取得了很大的成功。 我们已经能够开发控制器中的核心服务，并在多个项目中重用这些服务。 控制器层也有助于unit testing和代码重用。