【发布时间】：2010-12-17 17:52:39
【问题描述】：
刚开始研究mvc，还不确定我是否掌握了它。据我所知，它似乎是一个 3 层解决方案的实现，即模型对应于 DAL，控制器对应于业务逻辑层，视图作为表示层。
我离基地很远吗？
【问题讨论】：
标签： asp.net-mvc separation-of-concerns 3-tier
【发布时间】：2010-12-17 17:52:39
【问题描述】：
我告诫不要将模型简单地视为数据访问层。这过于简单化了，它会导致您将过多的代码放入控制器层。最好将更多的代码放在模型中，并使数据库持久性仅是模型内部代码的一部分。我喜欢这样想 MVC：
- 控制器：处理输入，确定要实例化的模型和视图
- 视图：应用程序数据的呈现
- 模型：应用程序的所有其他逻辑，包括但不限于 DAL
这基本上是Page Controller 模式。
另一种思考方式是：假设您必须将 Web 应用程序移植到另一个平台，例如命令行应用程序或桌面 GUI 应用程序。您应该重用应用程序逻辑的哪些部分？当您将应用程序移植到另一个平台时，控制器和视图会发生变化，因为输入和输出的实现都需要更改。不需要更改的代码应该在您的模型中实现。
如果您正确地进行了关注点分离，那么模型、视图和控制器的耦合将最小化，您可以更改其中一个的实现而不会过多影响其他的实现。如果您更改了模型，并且发现自己在控制器或视图中重写了大量代码，那么您可能没有充分分离这些层。反之亦然。
阅读 Martin Fowler 的 Anemic Domain Model 反模式或 Domain Driven Design Quickly 以获得其他观点。
另请参阅我写的blog from 2008，以回应人们谴责 Active Record 模式。它得到了一些很好的 cmets 和讨论。
【讨论】：
-
我同意。瘦控制器和胖模型让我的生活更轻松。
有点。它看起来像这样：
今天最常用的模式是：
Database -> DAL -> BLL -> Controller -> View Model -> UI
在哪里
DAL == Data Access Layer (aka ORM, Object-Relational mapper)
BLL == Business Logic Layer
请注意，您并不总是需要每一层。例如，如果应用程序足够小，BLL 和 View Model 可以是可选的。
您应该查看NerdDinner tutorial.，它在一个参考中描述了所有这些概念。
【讨论】：
如果您是 MVC 新手，这里有一些很好的解释：
【讨论】：
简短的说明，当您说控制器可以（不一定）是业务层，而视图是表示层时，您是正确的。
但是，模型是包含数据的对象（取决于实现），而数据层是检索/操作数据的层。
【讨论】：