我应该如何构建一个简单的ASP.NET MVC应用程序？ [英] How should I structure a simple ASP.NET MVC app?
问题描述
我一直在阅读有关ASP.NET MVC，固体和一些事情等等，我试图找出为小到中等ASP.NET MVC应用程序，将使这些概念的简单的良方一起;我最关心的与控制器，过于复杂结束时和像web表单code隐藏文件，与所有类型的业务逻辑放进去的问题。
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:
- 控制器：只处理请求，调用相应的服务和行动结果返回给浏览;
- 型号：POCO，处理所有的业务逻辑，授权等依赖于信息库，一无所知的持久性基础设施
- 库：实施
IRepository＆LT; T＆GT;，使用依赖注入，是在我的分贝code将驻留;只接收和返回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.
最后，应该有单元测试覆盖模型code和单位+覆盖库code集成测试（继红 - 绿的做法，如果可能的话）
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 had a good post on exactly this recently:
这篇关于我应该如何构建一个简单的ASP.NET MVC应用程序？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
