Asp.net MVC 是否有助于创建 n 层解决方案？答案

【问题标题】：Does Asp.net MVC help creating n-tier solutions?Asp.net MVC 是否有助于创建 n 层解决方案？
【发布时间】：2009-06-03 00:03:15
【问题描述】：

我的看法是它和它没有。

它将逻辑和数据从 UI 中分离出来，但仍将它们全部塞进一个单点应用程序中。
这就是为什么我认为它不是真的，因为控制器是业务逻辑，视图是 UI，模型是 DAL。这些现在只是同一个应用中的层。

但是层应该是第一个还是第二个变种，实际上被称为层？

有人想自己加 2 美分吗？

【问题讨论】：

“crams”是不必要的情绪化，另一种观点（我的）可能是组件实际上被清晰清晰地描绘 - 只要这些部分是正交的，线条就是任意的
控制器不应该包含业务逻辑——这是模型的作用。模型背后的内容可能是 n 层的，也可能不是所需的。 MVC 本质上是一种 UI 模式。

标签： asp.net-mvc n-tier-architecture

【解决方案1】：

MVC 模板项目只是为了帮助您入门 - 如果您愿意，并且在您的应用程序中有意义，您可以轻松将控制器和/或模型移出到单独的项目中。请记住，对于可能包含三个控制器、模型层中的几个额外类以及一个 EF 或 LINQ 数据模型的小型应用程序，您确实没有足够的文件来证明将其分成不同的项目是合理的。

【讨论】：

【解决方案2】：

我不认为控制器是业务逻辑。它们是应用程序逻辑，是将业务逻辑（模型）和表示逻辑（视图）联系在一起的粘合剂。

【讨论】：

您不认为业务逻辑（如在业务流程中）不是模型的一部分吗？模型只是业务流程的数据存储......
但是您对控制器的看法是正确的。它们不是实际的业务流程逻辑。他们只是为他们服务。我认为应该有一个单独的部分：“流程”，它将控制器和模型粘合到实际的业务层中。

【解决方案3】：

嗯，我的生日蛋糕有层，但它仍然是一个大蛋糕......所以是吗？

【讨论】：

【解决方案4】：

当然可以！

我认为视图和控制器都包含用户界面逻辑......业务逻辑应该在模型中（不仅仅是 DAL）。

作为您可以使用的模型，例如CSLA objects 并根据需要添加另外几个物理层（通过配置）。

您必须知道逻辑层和物理层（或层与层）之间存在差异...

lhotka 的网站上有很多关于这个主题的有趣文章！
例如。 this one 和 this one。

【讨论】：

【解决方案5】：

层和层是可互换的。在 n 层的上下文中，您将其称为表示层，但在分层应用程序的上下文中，您将其称为表示层。但实际上它们是一回事。

对 n 层应用程序和松散耦合的试金石是，您是否可以将每一层作为单独的项目构建并部署在不同的机器上。

n 层应用的关键区别在于关注点分离 (SoC) 和低耦合。一个真正解耦的应用程序可能是一个只包含纯 HTML 的层。然后另一个包含纯 Javascript 并使用 AJAX 更新 DOM 并与 Web 服务通信。 Web 服务包含它自己的一组层。

Web 服务有一个路由引擎，可以将请求路由到不同的控制器。控制器清理和解释请求，验证身份验证和不验证的内容，并调用适当的模型。反过来，模型必须返回 POCO 对象或 DTO 并将它们返回给将它们注入 DOM 的 Javascript。 Javascript 可能会修改对象并将它们发送回以持久保存到数据库中。 Entity Framework 4.0 对 n-tier scenarios 提供了很好的支持，尽管它在 SoC 部门中确实有点不足（例如强类型视图），但它对于更多用途来说是实用的。

我相信 MVC Futures 支持一些开箱即用的控制反转 (IoC) 容器，目前如果您想要松散耦合和真正的 n 层场景，您可能需要使用您选择的 IoC 容器。

【讨论】：

【解决方案6】：

“层”通常是指不同的物理服务器，而“层”是指将功能分离为松散耦合的区域。

也就是说，一个 3 层的 Web 应用程序：第 1 层）数据库服务器第 2 层）网络服务器第 3 层）客户端浏览器

三层网络应用：第 1 层）用户界面第 2 层）业务逻辑第 3 层）数据访问

【讨论】：

我不知道这是否真的回答了这个问题，除了：“你可以用任何语言编写 FORTRAN”，但是 MVC 有点推动你朝着正确的方向前进。
@mgroves：我认为这与这个问题非常相关，因为显然提问者将这两个术语混为一谈。（另请参阅我的回答和有关此主题的链接）