MVC——它只是一个三层模型吗？
刚刚开始研究mvc，还不确定我是否掌握了它。据我所知，这似乎是一个 3 层解决方案的实现，即模型对应于 DAL，控制器对应于业务逻辑层，视图对应于表示层。
我在这里离基地很远吗？
Just began researching mvc, and am not sure I grasp it yet. From what I gather it seems like an implementation of a 3 tier solution ie Model corresponds to DAL, Controller to business logic layer, and View as Presentation layer.
Am I way off base here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我警告不要将模型简单地视为数据访问层。这过于简单化了，它会导致您在控制器层中放入太多代码。最好将更多代码放入模型中，并使数据库持久性仅成为模型内部代码的一部分。我喜欢这样思考 MVC：
这基本上是 页面控制器模式。
另一种思考方式是：假设您必须将 Web 应用程序移植到另一个平台，例如命令行应用程序或桌面 GUI 应用程序。您应该重用应用程序逻辑的哪些部分？当您将应用程序移植到另一个平台时，控制器和视图会发生变化，因为输入和输出的实现都需要更改。不需要更改的代码应该在您的模型中实现。
如果您正确地进行了关注点分离，那么模型、视图和控制器将是最低限度耦合的，并且您可以更改其中一个的实现，而不会过多影响其他的实现。如果您更改模型并发现自己在控制器或视图中重写了大量代码，则您可能没有充分分离这些层。反之亦然。
了解 Martin Fowler 的 贫血域模型 反模式或 快速进行领域驱动设计以获得一些其他观点。
另请参阅我在 2008 年撰写的 博客对人们谴责 Active Record 模式的回应。它得到了一些很好的评论和讨论。
I caution against treating the Model as simply a data access layer. That's oversimplifying, and it results in you putting too much code into the Controller Layer. It's better if you put more of that code in the Model, and make database persistence only a part of the Model's internal code. I like to think of MVC like this:
This is basically the Page Controller pattern.
Another way to think about it is this: suppose you had to port your web app to another platform, such as a command-line app or a desktop GUI app. What parts of the application logic should you reuse? The Controller and View would change as you port your app to another platform, because the implementation of both input and output would need to change. The code that doesn't need to change should be implemented in your Model.
If you've done the separation of concerns right, then the Model, View, and Controller would be minimally coupled, and you could change the implementation of one without affecting the others too much. If you change the Model and you find yourself rewriting a lot of code in the Controller or the View, you probably haven't separated these layers adequately. And vice versa.
Read about Martin Fowler's Anemic Domain Model antipattern or Domain Driven Design Quickly to get some other perspectives.
Also see my blog from 2008 that I wrote in response to people decrying the Active Record pattern. It got some good comments and discussion.
有点像。它看起来像这样：
今天最常用的模式是：
其中
请注意，您不这样做并不总是需要每一层。例如，如果应用程序足够小，则 BLL 和视图模型可以是可选的。
您应该查看 NerdDinner 教程。 它在一个参考中描述了所有这些概念。
Sort of. It looks like this:
The pattern most commonly used today is:
Where
Note that you don't always need every layer. The BLL and View Model, for example, can be optional if the app is small enough.
You should check out the NerdDinner tutorial. It describes all of these concepts in a single reference.
如果您是 MVC 新手，这里有一些很好的解释：
我旁边还有人不懂 ASP.NET MVC 吗？
Some great explanations here if you're new to MVC:
Does anyone beside me just NOT get ASP.NET MVC?
简短说明，当您说控制器可以（不一定）是业务层，而视图是表示层时，您是正确的。
然而，模型是包含数据的对象（取决于实现），而数据层是检索/操作数据的层。
A short note, you are correct when you say the Controller can (doesn't have to) be the business layer, and the view is the presentation layer.
However the model are the objects (depending on implementation) that contain the data, whereas a data layer is a layer that retrieves/manipulates data.