与老式的 3 层模式相比，MVC 模式的主要优点是什么
我正在考虑在我的新项目中使用 MVC 模式，我可以清楚地看到能够将数据层（模型）稍微靠近表示层（视图）的主要优点，这将允许稍微增加在应用速度方面。但除了性能角度之外，MVC 相对于视图-逻辑-数据分层类型模式还有其他优势吗？
编辑： 对于那些感兴趣的人，我刚刚上传了一个示例 PHP 代码，该代码是我为测试 MVC 的使用而创建的。我故意省略了所有安全检查，以使代码更易于阅读。请不要过多批评它，因为我知道它可以更加精致和先进，但尽管如此 - 它有效！我欢迎提出问题和建议：这是链接：http:// /www.sourcecodester.com/sites/default/files/download/techexpert/test_mvc.zip
I am contemplating about using an MVC pattern in my new project and I can clearly see the main advantage of being able to put the data layer (the model) a little closer to the presentation layer (the view), which will allow a little increase in application speed. But apart from performance stand point are there any other advantages of MVC over the view-logic-data layered type pattern?
EDIT:
For those who's interested I just uploaded a sample PHP code that I created to test the use of MVC. I purposly omitted all the security checks to make the code a little easier to read. Please don't critisize it too much, because I know it could be a lot more refined and advanced, but nevertheless - it works!!! I will welcome questions and suggestions: Here is the link: http://www.sourcecodester.com/sites/default/files/download/techexpert/test_mvc.zip
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
被认为是 MVC 优点的关注点分离实际上也是 3 层/3 层系统的进步。在那里，业务逻辑也是独立的，可以从不同的表示层使用。
主要区别在于，在经典 MVC 中，模型可以引用回视图。这意味着当数据更新时，模型可以将该数据推送回可能的多个视图。主要的例子是桌面应用程序，其中数据以多种方式可视化。这可以像表格和图表一样简单。表中的更改（即一个视图中的更改）首先通过控制器推送到模型，然后模型将其推送回图表（另一个视图）。然后图表会自行更新。
由于桌面开发正在衰落，许多程序员仅在某些 Web 变体中接触过 MVC，例如通过 Java EE 中的 JSF。
在这些情况下，模型几乎从不引用视图。这是因为网络主要是基于请求/响应的，并且在处理请求后，服务器无法发送附加信息。即从模型推送到客户端的更新是没有意义的。通过反向 ajax/comet，这种情况正在改变，但许多基于 Web 的 MVC 框架仍然没有充分利用这一点。
因此，在基于 Web 的 MVC 的情况下，M、V 和 C 之间的典型“三角形”较少，并且该 MVC 变体实际上比“真正的”MVC 更接近 n 层模型。
另请注意，某些 Web MVC 框架在 M、V 和 C 之间有一个中间管道部分，称为支持 bean (Java/JSF) 或代码隐藏 (ASP.NET)。在 JSF 中，控制器由框架提供，视图通常不直接绑定到模型，而是使用此支持 bean 作为中介。支持 bean 非常薄，基本上只是以一种方式从模型中预取数据，并将模型特定消息（例如异常）转换为视图特定消息（例如一些人类可读的文本）。
The separation of concerns that's quoted as being an advantage of MVC is actually also an advance of a 3-layer/3-tier system. There too, the business logic is independent and can be used from different presentation tiers.
A main difference is that in classic MVC the model can have a reference back to the view. This means when data is updated the model can push this data back to possibly multiple views. The prime example is a desktop application where data is visualized in multiple ways. This can be as simple as a table and graph. A change in the table (which is a change in one view) is first pushed via the controller to the model, which then pushes it back to the graph (the other view). The graph then updates itself.
Since desktop development is on the decline, a lot of programmers have only come in touch with MVC in some web variant, e.g. via JSF in Java EE.
In those cases the model almost never has a reference to the view. This is because the web is mainly request/response based and after a request has been served, the server cannot send additional information. I.e. an update pushed from the model to the client would be meaningless. With reverse ajax/comet this is changing, but many web based MVC frameworks still don't fully utilize this.
Thus, in the case of web based MVC, the typical "triangle" between M, V and C is less there and that MVC variant is actually closer to an n-tier model than 'true' MVC is.
Also note that some web MVC frameworks have an intermediate plumbing part between M, V and C called a backing bean (Java/JSF) or code behind (ASP.NET). In JSF the controller is provided by the framework, and the view often doesn't bind directly to the model but uses this backing bean as an intermediary. The backing bean is very slim and basically just pre-fetches data from the model one way and translates model specific messages (e.g. exceptions) into view specific messages (e.g. some human readable text).
除了
@bakoyaro 和 @arjan 已经提到过）
之外，我认为 MVC 与“约定优于配置”模式结合使用时比 3 层更好。 （即“ruby on Rails”或 Microsoft 的“MVC for asp.net”）。
在我看来，这种组合可以更好、更轻松地维护代码。
首先，它使学习 mvc 框架变得更加困难，因为您必须学习约定（la 控制器进入控制器文件夹，并且必须命名为 xxxxxcontroller），
但是在学习了约定之后，维护自己的约定会更容易和外国代码。
Beside
already mentioned by @bakoyaro and @arjan
i think that MVC is better than 3-tier when combined with the "convention over configuration" pattern. (i.e. "ruby on rails" or Microsofts "MVC for asp.net").
In my opinion this combination leads to to better and easier code maintanance.
In the first place it makes learning the mvc-framework a bit more difficuilt since you have to learn the conventions (a la controllers go into the controllers folder and must be named xxxxxcontroller)
But after you learned the conventions it is easier to maintain your own and foreign code.
忘记通过迁移到 MVC 来提高应用程序速度。我发现最大的好处是易于代码重用。一旦迁移到 MVC，就不再依赖于数据的表示或实际数据的存储。
例如，您可以有一天编写一个提供 .jsp 页面的 servlet 作为表示层，第二天编写一个 Web 服务作为现有模型和控制器的另一个表示层。同样，如果您想要或需要切换 DBMS。由于访问模型与其他所有内容完全分开，因此您只需要重写数据访问对象即可以控制器可以处理的方式返回数据。
通过将关注点分成 3 个不同的部分，您还可以促进真正的单元测试。您的表示层可以在没有模型或控制器的情况下进行测试，反之亦然。
顺便说一句，我经常觉得 MVC 缩写是不准确的。每当我看到它时，我都会将其视为视图->控制器->模型。表示层中永远不会有 DAO 代码，模型中也永远不会有表示逻辑。控制者被迫充当中间人。
Forget increasing application speed by moving to MVC. I have found the biggest benefit to be ease of code reuse. Once you move to MVC, there are no dependencies on the presentation of your data or the storage of the actual data.
For example you could write a servlet that served up .jsp pages as your presentation layer one day, and the next day write a web service as another presentation layer to your existing Model and Controller. Like wise if you want or need to switch your DBMS. Since accessing the Model is completely separate from everything else, you would just need to re-write just your data access objects to return the data in a way your Controller can handle it.
By separating concerns into 3 distinct pieces, you also facilitate true unit testing. Your Presentation layer can be tested free of the Model or Controller, and vice-a-versa.
On a side note, I've often felt that the MVC abbreviation was inaccurate. Whenever I see it I think of it as View->Controller->Model. The presentation layer will never have DAO code in it, and the model will never have presentation logic in it. The Controller is forced to act as a go-between.
3 层将表示与业务和数据访问分开，MVC 是一种表示层模式，进一步将模型（数据）与视图（屏幕）和控制器（输入）分开。
没有选择 MVC 而不是 3 层/3 层。两者都使用。
Where 3-tier separates presentation from business and data access, MVC is a presentation layer pattern which further separates Model (data) from View (screen) and Controller (input).
There is no choosing MVC over 3-tier/3-layered. Use them both.