MVC 应用程序。 多层架构如何适应？
我对 MVC 和多层 Web 架构的概念很陌生。 我正在开发一个 PHP 应用程序，并使用可用的 MVC 框架之一。 我的问题如下：
据我了解，MVC 本身并不被视为多层架构。 我可以理解单独使用 MVC 是如何比采用非结构化方法进步了一步，但我正在考虑简单的 3 层架构如何适应？ MVC 会驻留在表示层吗？ 添加分层方法有哪些优点？ 据我所知，仅使用 MVC 就没有明确的数据对象负责从数据库检索数据，这通常会被填充到模型中。 同样，业务逻辑（在 3 层架构中驻留在“业务层”（或任何您想要的名称）中）可以填充到控制器中。
我的理解有些正确吗？ 我知道我问了很多问题，但我想听听您讨论如何将 n 层架构合并到 MVC 框架（PHP 或其他）中，因为我认为两者并不相互排斥。 谢谢！
I am new to the concept of MVC and multi-tiered web architecture. I developing a PHP application and am using one of the available MVC frameworks. My question is as follows:
From what I understand, MVC in and of itself is not considered a multi-tier architecture. I can understand how using MVC alone is a step up from taking an unstructured approach, but I was contemplating how a simple 3-tier architecture would fit in? Would MVC reside in the presentation layer? What are the merits of adding a tiered approach? From what I gather, with MVC alone there are no explicit data objects responsible for retrieving data from the database and this is usually stuffed into the model. Likewise the business logic, which in a 3-tiered architecture would reside in a 'business-layer' (or whatever you want to call it), can be stuffed into the controller.
Is my understanding somewhat correct? I know I asked a lot of questions, but I would like to hear you discuss how you incorporated an n-tier architecture into your MVC framework (PHP or otherwise) as I assume that the two are not mutually exclusive. Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
M) M 是你的模型。 这通常位于业务层或表示层后面的层中。 许多人不喜欢表示层了解业务层的任何知识，因此他们通过所谓的 ViewModel 进一步抽象。 这些通常是松散映射到域模型的 DTO（数据传输对象）。 对于我（.net 人）来说，有 AutoMapper 等工具可以将域模型转换为视图模型。
V) V 是你的观点。 视图是您的表示层。 这是用户直接接触和交互的实际 HTML 或 PHP 代码。 视图应该尽可能简单（意味着如果可能的话没有逻辑）。 尝试将任何类型的 if/then 类型场景排除在视图之外，并坚持仅显示和收集数据。 向您的网页设计师展示 ViewModel，这样他们就不会污染您的 DomainModel。
C) C 是您的控制器。 这很像一个协调员。 它从您的视图中获取数据，并确保它到达正确的后端函数/方法来处理该数据。 它还协调从后端到前端的数据。
多层设计概念出现在表示层的后面（这是 MVC 主要存在的地方）。 当控制器从视图获取数据并将其传递回后端时（如果您遵循 DDD 或域驱动设计），它会将数据传递给应用程序服务（协调后端事务的类）。 该服务可能会进一步将数据推送到存储库层（这是一个与数据库、文件系统、Web 服务等 - 任何基础设施相关的类）。 DDD 是一个很大的主题，但会让您了解 n 层方法以及它如何与 MVC 配合使用。
在研究这个主题时，请了解一下 IoC（控制反转）、DI（依赖注入）、TDD（测试驱动开发）以及尽可能多的模式（外观、工厂等）。
M) M is your model. This is generally living in your business layer or the layer just behind your presentation layer. Many people don't like the presentation layer to have any knowledge of the business layer though and so they further abstract that by having what is called a ViewModel. These frequently are DTO (data transfer objects) that loosely map to your Domain model. For me (.net guy) there are tools such as AutoMapper to make the conversion from Domain Model to View Model.
V) V is your view. The view is your presentation layer. This is the actual HTML or PHP code that the user directly touches and interacts with. The view should be as light as possible (meaning no logic if possible). Try to keep any sort of if/then type scenarios out of the view and stick to just displaying and collecting data. Present a ViewModel to your web designers so that they don't contaminate your DomainModel.
C) C is your controller. This is much like a co-ordinator. It takes data from your view and makes sure it gets to the right back end function/method for processing that data. It also co-ordinates data from the back end on it's way to the front end.
Where multi-tier design concepts come in is behind the Presentation layer (where is where MVC is primarily). When the controller is taking data from the view and passing it back to the back end it (if you follow DDD or Domain Driven Design) would pass the data to an application service (a class that co-ordinates back end matters). The service might further push the data into a Repository layer (which is a class that speaks to the database, filesystem, web services, etc. - any infrastructure stuff). DDD is a big topic but will get your head around the n-tier approach and how it works with MVC.
While researching this topic take a look at IoC (inversion of control), DI (dependency injection), TDD (test driven development), and as many patterns as possible (facade, factory, etc.).
一般来说，业务逻辑不应该在控制器中 - 如果遵循这种模式，您最终会得到大量控制器。 该模型基本上包含所有非表示层……数据访问、业务逻辑和业务实体对象。 您的控制器为视图准备业务数据。
In general, business logic should not be in the Controller - you'd end up with massive controllers if you followed this pattern. The Model basically houses all your non-presentation layers ... data access, business logic, and business entity objects. Your controller prepares the business data for the view.