“纯粹的”MVC实现有用吗？

Question

我在一家提供定制“CRM”软件的公司工作。我们目前正在重新设计/重新开发该软件，希望它看起来更现代，更容易为未来的客户开发和定制。目前，定制每个新应用程序需要很长时间。

有一种假设认为它花费这么长时间的原因是因为“视图”层中存在的业务逻辑量。在某种程度上，我可以保证这是真的，但症状并不总能可靠地指出原因。有一个建议是，如果我们只是将业务逻辑移动到控制器层并使用纯视图（我们使用java J2EE和struts），就像实现struts标签而不是调用bean层并在jsp上迭代对象 - 等等。

在我开始提倡之前，我们继续这样做，我想要了解其他人的想法。 MVC的“纯粹”实现（特别强调解耦控制器和视图）是否提供了更清晰，更易于开发和更改的代码库？

感谢大家的投入 - 这已经帮助了很多

Answer 1

您的目标应该是将您的业务逻辑放在一个地方。根据我的经验，如果你能做到这一点，你的代码库将更容易开发，维护和更改。

模型 - 视图 - 控制器是达到这一点的一种方式，但在经典MVC中，业务逻辑在（域）模型中，而应用程序逻辑在控制器中。

应用程序逻辑：如果用户的下一个检查日期在一周内（或过期），则显示“计划检查”屏幕，否则显示“检查历史记录”屏幕。

商业逻辑：以前检查失败的餐馆需要每六个月检查一次，每年必须检查海鲜餐馆，所有其他餐馆必须每两年检查一次。鉴于这家餐厅的最后一次检查，他们的下次检查何时到期？

Answer 2

解耦始终如此。无论如何，MVC与否，系统中的耦合越少，维护和更改就越容易。 MVC只是Web的良好模式，简化了解耦，就是这样。

Answer 3

MVC建议智能被恰当地隔离。这意味着，视图和模型会有点愚蠢，控制器是真正聪明的人。这意味着我们可以顺利地创建修改愚蠢的家伙和聪明人。当需求/代码修复有效开启时，这些好处将大​​大增加。增加的抽象是一种痛苦，直到人们掌握所使用的模式。这是服务器端的MVC。客户端代码上的MVC怎么样？

有时，视图模型内置了不同的智能并被编码到业务代表中。但是，更好的方法是使用自定义标签。关于jsp页面最烦人的事情发生在他们将javascript与代码混淆时，这个智能代码实际上试图操纵DOM并在静态jsp代码中产生无法匹配的标签。

因为你有从头开始的奢侈。如果每个人都使用不引人注目的javascript（一种与java不同的语言，比我在生产代码中看到的狗屎更容易）和自定义标签（并不那么困难），生活会更简单。另一个痛点是没有符合W3C标准的html / css。如果你是他们的话，浏览器问题会带来巨大的麻烦。

P.S：长期咆哮的应用：）

Answer 4

有人这样说：

“计算机科学中的任何问题都可以通过另一层间接解决”

但我不记得这句话的作者是谁。有人知道吗？

Answer 5

我在一家非常严格遵循MVC的公司工作，我们已经取得了很大的成功。我们已经能够开发控制器中的核心服务，并在多个项目中重用这些服务。控制器层也有助于单元测试和代码重用。