MVC（ASP.NET MVC）带3层架构如何协同工作？
我正在编写一个设计文档，我的团队中的人员愿意从 ASP.NET WebForm 迁移到 ASP.NET MVC。这很棒，但我很难理解 MVC 如何在 3 层（数据层、业务层和表示层）架构中工作。我们可以说模型、视图和控制器是表示层的一部分吗？模型是业务层的一部分吗？
简而言之，MVC 和 3 层架构如何协同工作？感谢您的帮助！
I am writing a design document and people on my team are willing to do the move from ASP.NET WebForm to ASP.NET MVC. This is great, but I have a hard time to understand how MVC workswith in a 3-tier (Data Layer, Business Layer and Presentation Layer) architecture. Can we say that the Model, View and Controller are part of the Presentation Layer? Is the Model part of the Business Layer?
In brief, how MVC and 3-tier architecture can work together? Thanks for the help!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我认为 ASP.Net MVC 位于表示层。它使用的“模型”类实际上是视图模型，它描述视图所需的数据结构。您的所有业务逻辑和数据访问都应与 MVC 模型和控制器保持分离。
此外，MVC 的一般“最佳实践”是使控制器代码尽可能简单，这通常意味着将一些应用程序服务引入到处理繁重工作的业务层中。
I consider ASP.Net MVC to be in the presentation layer. The "Model" classes it uses are really View Models, which describe the data structures needed by your views. All of your business logic and data access should remain separate from your MVC models and controllers.
Also, the general "Best Practice" for MVC is to keep the controller code as simple as possible, which usually means introducing some for of application service into your business layer that handles the heavy lifting.
表示层是您的视图。
数据层是您的模型（建议查看存储库模式）。
业务层保持原样。
加载对象时，控制器可以调用业务层的功能，或者当请求特定 ViewModel 时，模型可以调用业务层的功能，但其他方面保持不变。
控制器中不应包含扩展的业务逻辑——将其放入其自己的独立 DLL 中。
The presentation Layer is your View.
The Data Layer is your Model (recommend looking at the Repository Pattern).
The Business Layer remains what it is.
The Controller can call the business layer for functionality when the object is loaded, or the model can call the business layer for functionality when a specific ViewModel is requested, but otherwise it remains the same.
The controller shouldn't have expansive business logic in it -- put that in its own self-contained DLL.
这是相当主观的。 做对你的团队有意义的事情。
MVC 非常灵活，几乎没有一个跨所有语言的 MVC 框架都以相同的方式做事。即使在 .net 空间中也是如此。 FubuMVC、Spring.net 和 MS MVC 的工作方式都略有不同。
This is pretty subjective. Do what makes sense to your team.
MVC can be pretty flexible and almost no MVC framework, across all languages, does things the same way. Even in the .net space. FubuMVC, Spring.net, and MS MVC all do things in slightly different ways.
首先，
你不必仅仅因为......如果你有一些有效的东西，我认为你不需要改变到MVC。
但对于你的问题，MVC 模式中的模型是代表你的业务问题的任何类型的类，可以是任何类型的计算、业务规则或数据访问类。在 MVC 框架中，有一个文件夹可以为您提出解决方案，因此您可以将模型类放在其中，但您不必这样做，您可以创建不同的项目来解决您的业务问题，这就是您的模型。
因此，在这里，您可以定义任何其他模式，您可以使用存储库模式并使用 NHibernate 或实体框架来实现。
视图只是向用户显示和接收信息的网页。
控制器是应用程序的入口，这些类将接收请求、调用必要的模型并重定向到指定的视图。
希望我能帮忙。
First of all,
you don't have to change to MVC just because... If you have something that is working I don't think you need to.
But to you question, the Model in the MVC pattern is any kind of class that represents your business problem, wich can be any sort of calculation, business rules or data access classes. In the MVC framework there's a folder as a way to propose a solution for you, so you can put your model classes in there, but you don't have to, you can create different projects so solve your business problems and that's your Model.
So here, you can define any other patter that you for instante, you can use the Repository Pattern and implemente that using NHibernate or Entity Framework.
The Views are just web pages to show and receive information to and from the user.
And the controller is the entrance to your application, the classes that are going to receive the requests, call the necessary models and redirect to the specified view.
Hope I could helped.
N-Tier 与 MVC 配合得很好。只需遵循 SOLID 原则和其他一些原则，您就能够保持应用程序松散耦合和内聚。
我想说，阅读有关 MVC 3 的书籍和观看pluralsight.com 视频是您最好的资源。你不能选择“做对你的团队有用的事情”。如果说名为 Johnny 和 Timmy 的工作伙伴想要将一堆逻辑放入控制器中，只是因为在短期内截止日期紧迫，“适合您的团队”，但这并不意味着它是正确的/良好的/聪明的。
我在互联网上发现了如此多的不良文章，令人恐惧的是，有多少人正被引导走上一条黑暗的痛苦之路。走幸福之路。使用 stackoverflow 获取艺术之类的观点，但请查看 msdn 文章、mvc 书籍和pluralsight.com
N-Tier with MVC works just fine. Just follow SOLID principle and several others and you will be able to keep your application loosely coupled and cohesive.
I would say that reading the books on MVC 3 and watching pluralsight.com videos are your greatest resources. You can't go with "do what works for your team." If say work associates named Johnny and Timmy want to put a bunch of logic into a controller, just because in the short term deadline rush that "works for your team" that doesn't make it right / good / smart.
I have found so many bad articles on the internet that it is scary how many people are getting led down a dark road of misery. Follow the happy path. Use stackoverflow for opinion like art, but check with msdn articles, mvc books, and pluralsight.com
我知道这只是一个维基百科链接，但是这里有一些关于 n 层的信息与 MVC 架构相比。
I know it's just a Wikipedia link, but there is some info here regarding n-tier vs. MVC architecture.
“层”是部署单元，而 MVC 中的“层”是代码内责任的逻辑分离。
A "Tier" is a unit of deployment, while a "Layer" in MVC is a logical separation of responsibility within code.