MVC 应用程序.多层架构如何适应? [英] MVC application. How does mult-tier architecture fit in?

问题描述

我是 MVC 和多层 Web 架构概念的新手.我正在开发一个 PHP 应用程序，并且正在使用可用的 MVC 框架之一.我的问题如下:

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:

据我所知，MVC 本身不被视为多层架构.我可以理解单独使用 MVC 如何比采用非结构化方法更进一步，但我正在考虑如何适应简单的 3 层架构?MVC 会驻留在表示层吗?添加分层方法的优点是什么?从我收集的信息来看，仅使用 MVC 就没有明确的数据对象负责从数据库中检索数据，这通常被填充到模型中.同样，在 3 层体系结构中，业务逻辑将驻留在业务层"(或任何您想调用的地方)中，可以填充到控制器中.

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.

我的理解有点正确吗?我知道我问了很多问题，但我想听听您讨论如何将 n 层架构合并到您的 MVC 框架(PHP 或其他)中，因为我认为这两者并不相互排斥.谢谢！

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!

推荐答案

M) M 是您的模型.这通常位于您的业务层或表示层后面的层中.许多人不喜欢表示层对业务层有任何了解，因此他们通过拥有所谓的 ViewModel 来进一步抽象.这些通常是松散映射到域模型的 DTO(数据传输对象).对我(.net 人)来说，有 AutoMapper 之类的工具可以将领域模型转换为视图模型.

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 是你的观点.视图是您的表示层.这是用户直接接触和交互的实际 HTML 或 PHP 代码.视图应该尽可能轻巧(如果可能，意味着没有逻辑).尝试将任何类型的 if/then 类型场景排除在视图之外，并坚持只显示和收集数据.向您的网页设计师展示一个 ViewModel，以免他们污染您的 DomainModel.

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 是您的控制器.这很像一个协调员.它从您的视图中获取数据并确保它到达正确的后端函数/方法来处理该数据.它还协调从后端到前端的数据.

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.

多层设计概念出现在表示层之后(MVC 主要存在的地方).当控制器从视图中获取数据并将其传递回后端时，它(如果您遵循 DDD 或域驱动设计)会将数据传递给应用程序服务(协调后端的类很重要).该服务可能会进一步将数据推送到存储库层(这是一个与数据库、文件系统、Web 服务等对话的类 - 任何基础设施).DDD 是一个很大的话题，但会让您了解 n 层方法以及它如何与 MVC 配合使用.

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.

在研究此主题时，请查看 IoC(控制反转)、DI(依赖注入)、TDD(测试驱动开发)以及尽可能多的模式(外观、工厂等).

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.).

这篇关于MVC 应用程序.多层架构如何适应?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！