遵循最佳编程实践的 Asp.Net Mvc 应用程序所需/推荐的所有层的细分是什么？
我对 Asp.Net MVC 的了解越多，我发现需要更多的层和组件才能使我的应用程序遵循所有标准和最佳编程实践。
它开始变得有点混乱，因为一些新层似乎不像我学到的其他层那么容易适应。 所以我只是想让有人回顾一下 Asp.Net MVC 应用程序的所有必需/推荐层 - 它们的用途是什么以及它们如何与其他层交互。
以下是我发现的一些层以及它们如何链接： （其中一些可能是错误的）
View/UI --> Model Binder --> Controller --> Service Layer --> Repository --> Entity Framework/LINQ to SQL --> DB
有人可以回顾一下我可能遗漏的内容，它们是如何联系起来的，以及它们各自的目的是什么？
谢谢，
马特
The more I read into Asp.Net MVC the more layers and components I find out are required in order to make my application follow all of the standards and best programming practices.
It's starting to get a bit confusing because some of the new layers don't seem to fit in as easily as the others I learnt. So I just wanted someone to go over all of the required/recommended layers for an Asp.Net MVC application- what purpose they serve and how they interact with the other layers.
Here's a few of the layers I've found and how they link up:
(Some of them may be wrong)
View/UI --> Model Binder --> Controller --> Service Layer --> Repository --> Entity Framework/LINQ to SQL --> DB
Could someone go over ones I may be missing, how they all link up, and what each of their purposes are?
Thanks,
Matt
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
好问题，我认为您涵盖了我所见过的所有层：模态绑定器和服务层是可选的。
也许，您可以添加另一个错误处理层，例如 elmah。
Good question, I think you covered all the layers I have seen: Modal binder and service layer are optional.
Maybe, you can add another Error Handling layer such as elmah.
首先，我认为软件和模式有使事情变得过于复杂的倾向。 正如 ASP 名称所暗示的，该框架的主要思想是模型-视图-控制器 (MVC)。 您可以在这些组件之间放置很多东西，包括数据库、服务、API 等。但是，模型-视图-控制器模式的主要概念非常简单：将这些功能分离到模块中，以便项目可以更容易维护。
MVC 可以应用于您所做的任何编程或脚本。 即使对于 shell 脚本，MVC 也会有所帮助。 以下是每个示例的一些示例：
现在是好的部分。 控制器不关心视图如何管理与用户的交互。 它可以是命令行界面或 Web 表单。 控制器不知道数据是如何存储的，无论是数据库还是文件。 它只是请求数据并将其传递给视图。 它不关心视图如何获取输入，或者如何对数据进行建模。
那么问题来了，为什么我们要用这种模式让事情变得过于复杂呢？ 好吧，想象一下您有一个使用 MySQL DB 的 MVC 应用程序，并且知道您想要使用 SQL Server。 您应该更改哪个模块？ 显然，模特是受影响的人。 控制器和视图不应该有任何重大影响。 现在，想象一下您有另一个使用 Windows 窗体的 MVC 应用程序，现在您想将其更改为 Web 窗体？ 基本上，视图是会受到影响的视图（以及控制器的某些部分），但您的模型应该是相同的。
综上所述，MVC 是一个很棒的模式，应该多多使用。 然而，我认为有些项目由于 MVC 的简单性而不适合它。 这就像制造激光来杀死苍蝇一样。 当然，你会杀死他们，但并非在所有情况下都值得付出努力。
First of all, I think software and patterns have a tendency to overcomplicate things. As the ASP name implies the main idea of the framework is Model-View-Controller (MVC). You could be able to put a lot of things between these components, including DBs, Services, APIs, etc. However, the main concept of the Model-View-Controller pattern is pretty simple: Separate those functionalities into modules so the project could be easier to mantain.
MVC could be applied to ANY programming or scripting you do. Even for a shell script MVC could be helpfull. Here are some examples of each one:
Now the good part. The Controller does not care how the View is managing the interaction with the user. It could be a command line interface or a web form. The Controller does not know how the data is stored, it does not matters if it is a DB or a file. It just request data and pass it to the View. It not of its business to know how the view is getting the inputs, or the model the data.
Then the question, Why the hell do we want to overcomplicate things with this pattern? Well, Imagine that you have an MVC application using a MySQL DB and know you want to use SQL Server. What module you should change? Obviously the Model is the one affected. The Controller and the View should not have any major impacts. Now, imagine that you have another MVC application using Windows Forms, and now you want to change it to Web Forms? Well basically the View is the one that will be affected (and some parts of the controller), but your Model should be the same.
In summary, MVC is a great pattern, and it should be used more. However, I think there are some projects which are not suitable for MVC due its simplicity. It will be like building a laser to kill flies. Of course you will kill them, but the effort is not worthy on all cases.