一个“纯粹”的东西有多大用处？ MVC 实现？
我在一家提供类似“CRM”的定制软件的公司工作。我们目前正在重新设计/重新开发该软件，希望它看起来更现代，并且更容易为未来的客户开发和定制。目前，定制每个新应用程序都需要很长时间。
有一种假设是，花费这么长时间的原因是“视图”层中存在大量业务逻辑。在某种程度上，我可以保证这是真的，但症状并不总是可靠地指出原因。有人建议，如果我们只是将业务逻辑移至控制器层并使用纯视图（我们使用 java J2EE 和 struts），就像实现 struts 标签一样，而不是调用 bean 层并直接在 jsp 上迭代对象等。
在我开始提倡我们继续这样做之前，我想了解一下其他人的想法。 MVC 的“纯粹”实现（特别强调控制器和视图的解耦）是否提供了更清晰、更易于开发和更改的代码库？
感谢大家的意见 - 这很有帮助
I work at a company that provides custom made 'CRM'-like software. We are currently redesigning/redeveloping the software with the hopes that it will look more modern and be easier to develop and customize for future clients. Currently it takes a long time to customize each new application.
There is a presumption that the reason it takes so long is because of the amount of business logic that is present in the 'view' layer. To some extent I can vouch for this being true, but symptoms don't always reliably point out a cause. There was a suggestion that if we just move the business logic to the controller layer and use pure view (we use java J2EE and struts) as in implementing struts tags instead of calling the bean layer and iterating objects right on the jsp - etc etc.
Before I start advocating we go forward with this, I wanted to get a feeling for what other people thought. Does a "pure" implementation of the MVC (especially emphasis on decoupling the controller and the view) provide a cleaner, easier to develop and change code base?
Thank all of you for the input - that has helped alot
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您的目标应该是将业务逻辑集中到一处。根据我的经验，如果你能做到这一点，你的代码库将更容易开发、维护和更改。
模型-视图-控制器是达到这一点的一种方法，尽管在经典 MVC 中，业务逻辑位于（域）模型中，而应用程序逻辑位于控制器中。
应用逻辑：如果用户的下次检查日期在一周内（或逾期），则显示“安排检查”屏幕，否则显示“检查历史记录”屏幕。
业务逻辑：以前未通过检查的餐厅需要每六个月检查一次，海鲜餐厅必须每年检查一次，所有其他餐厅必须每两年检查一次。鉴于这家餐厅的上次检查时间，下次检查时间是什么时候？
Your goal should be to get your business logic in one place. In my experience, if you can do that, your code base will be easier to develop, maintain, and change.
Model-view-controller is a way to get to that point, though in classic MVC, the business logic is in the (domain) model, while application logic is in the controller.
Application logic: if the user's next inspection date is within a week (or past due), show the 'schedule inspection' screen, otherwise show the 'inspection history' screen.
Business logic: restaurants that have previously failed inspection need to be inspected every six months, seafood restaurants must be inspected every year, and all other restaurants have to be inspected every two years. Given this restaurant's last inspection, when is their next inspection due?
解耦总是能做到这一点。不管是否采用 MVC，系统中的耦合越少，维护和更改就越容易。 MVC 对于 Web 来说是一个很好的模式，它简化了解耦，仅此而已。
Decoupling always does that. Doesn't matter, MVC or not, the less coupling there in the system, the easier it is to maintain and change. MVC is just good pattern for Web, that simplifies decoupling, that's all.
MVC 建议适当地隔离智能。这意味着视图和模型有点愚蠢，而控制器才是真正的聪明人。这个含义让我们能够以流畅的方式创建修改愚蠢的家伙和聪明的家伙。当需求/代码修复有效时，这些好处就会得到巨大的体现。在掌握所使用的模式之前，添加的抽象是一种痛苦。这是服务器端的 MVC。客户端代码上的 MVC 怎么样？
有时，视图模型确实内置了不同的智能，并被编码到业务委托中。然而，更好的方法是使用自定义标签。对我来说，jsp 页面最烦人的事情发生在它们将 javascript 与代码混合在一起时，这种智能代码实际上试图操作 DOM，并导致静态 jsp 代码中出现不匹配的标记。
因为您有能力从头开始。如果每个人都使用不显眼的 javascript（一种与 java 不同的语言，比我在生产代码中看到的狗屎更容易）和自定义标签（没那么难），生活会更简单。另一个痛点是没有符合 W3C 的 html/css。对于浏览器问题来说，这是一个巨大的麻烦解决方案，如果你知道它们是什么。
PS：抱歉长篇大论：）
MVC suggests that intelligence be segregated appropriately.That implies, the view and model would be kind of dumb and controller is the actual smart guy. This implication lets us create modify dumb fellas and smart guys in a smooth fashion. These benefits are reaped hugely when the requirements/code-fixes are effectively on. The added abstractions are a pain until one gets a grasp of the patterns used. This is MVC on server side. What about MVC on client end code?
At times it is very true that view models have a different intelligence built into them and are coded into business delegates. However a better approach is to use custom tags. The most annoying thing about jsp pages for me occurs when they mix up javascript with the code, This smart code actually tries to manipulate DOM and results in unmatched tags in static jsp code.
As you have the luxury to start from scratch. Life would be simpler if everyone used unobstrusive javascript (a different language from java and easier than the shit I have seen in production code) and custom tags (not that difficult). Another pain point is not having W3C compliant html/css. A huge trouble saver with browser issues, if you what they are.
P.S: Appologies for the long rant :)
有人说过：
“计算机科学中的任何问题都可以通过另一层间接解决”，
但我不记得这句话的作者是谁。有人知道吗？
Someone said this:
"Any problem in computer science can be solved with another layer of indirection"
But I don't remember who is the author of this quote. Anybody knows?
我在一家非常严格遵循 MVC 的公司工作，并且我们在这方面取得了很大的成功。我们已经能够开发控制器中的核心服务，并在多个项目中重复使用这些服务。拥有控制器层也有利于单元测试和代码重用。
I work at a company that follows MVC pretty strictly and we've had a lot of success with it. We've been able to develop core services that live in the controller and re-use those on multiple projects. Have the controller layer also facilitates unit testing and code re-use as well.