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

Question

我的观点是和它没有。

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

但层是否应该是第一个或第二个实际上被称为 layers 的变种？

有人想加2美分？

Answer 1

MVC模板项目只是为了让您入门 - 如果您愿意，可以轻松将控制器和/或模型移出到单独的项目中，如果它在您的应用程序中有意义的话。请记住，对于一个可能有三个控制器的小应用程序，模型层中的一些额外类以及EF或LINQ数据模型，您实际上没有足够的文件来证明分离到不同的项目中。

Answer 2

我不认为控制器是业务逻辑。它们是应用程序逻辑，它将业务逻辑（Model）和表示逻辑（View）联系在一起。

Answer 3

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

Answer 4

当然可以！

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

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

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

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

Answer 5

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

对于n层应用程序和松散耦合的试金石测试是，如果您可以采用每个层并将它们构建为单独的项目并将它们部署在不同的计算机上。

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

Web服务有一个路由引擎，可以将请求路由到不同的控制器。控制器清理并解释请求，验证身份验证和不执行的操作，并调用相应的模型。反过来，模型必须返回POCO对象或DTO，并将它们返回到Javascript，然后将它们注入到DOM中。 Javascript可以修改对象并将它们发回以保存到数据库中。实体框架4.0对这样的n-tier scenarios提供了很好的支持，尽管它在SoC部门确实有点短（例如强烈地键入视图），但它可用于更多目的。

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

Answer 6

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

即3层Web应用程序： 第1层）数据库服务器 第2层）Web服务器 第3层）客户端浏览器

3层网络应用： 第1层）UI 第2层）业务逻辑 第3层）数据访问