我应该如何构建一个简单的 ASP.NET MVC 应用程序? [英] How should I structure a simple ASP.NET MVC app?
问题描述
我一直在阅读有关 ASP.NET MVC、SOLID 等的一些内容，我正在尝试为中小型 ASP.NET MVC 应用程序找出一个简单的食谱"，将这些概念一起;我最关心的问题是控制器过于复杂，就像网络表单中的代码隐藏文件一样，其中包含所有类型的业务逻辑.
I've been reading a few things about ASP.NET MVC, SOLID and so on, and I am trying to figure out a simple "recipe" for small-to-medium ASP.NET MVC apps that would put these concepts together; the issue that I am most concerned with is ending up with controllers that are too complex and being like code-behind files in webforms, with all type of business logic into them.
我正在考虑以下架构，用于小型数据驱动应用程序:
I am considering the following architecture, for a small data-driven app:
- Controllers:只处理请求，调用合适的服务，将动作结果返回给View；
- 模型:POCO，处理所有业务逻辑、授权等.依赖于存储库，完全不了解持久性基础设施.
- Repositories:实现
IRepository，使用依赖注入，是我的数据库代码所在的位置；只接收和返回 POCO.
- Controllers: only handle requests, call an appropriate service and return the action result to the View;
- Models: POCO, handle all the business logic, authorization etc. Depends on repositories, totally ignorant of persistence infrastructure.
- Repositories: implement
IRepository<T>, use dependency injection and is where my db code will reside; only receives and returns POCO.
我正在考虑在控制器和模型之间提供服务，但如果它们只是传递方法调用，我不确定它会有多大用处.
I am considering having services between the controllers and the models, but if they will just pass forward method calls I am not sure how useful it would be.
最后应该有覆盖模型代码的单元测试，以及覆盖存储库代码的单元+集成测试(如果可能，遵循红绿"实践)
Finally there should have unit tests covering the model code, and unit+integration tests covering the repository code (following the "red-green" practice, if possible)
想法?
推荐答案
Ian Cooper 最近发表了一篇很好的帖子:
Ian Cooper had a good post on exactly this recently:
这篇关于我应该如何构建一个简单的 ASP.NET MVC 应用程序?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
