MVC模式差异
我只需要一些链接到我可以阅读的文章或关于MVC（C＃）中使用的不同模式的一些基本解释。
目前，我倾向于使用视图模型模式构建我的Web应用程序。 对于每个视图，我都有一个视图模型。 我喜欢这种方法纯粹是因为模型中不需要那么多垃圾，我可以在这里使用一些基本的数据注释。
我现在也在视图模型中构建我的视图模型（不确定这是否正确？）这样我就可以让控制器尽可能简单。
有时候我发现自己在我的控制器中添加了很多逻辑，我认为这对我来说也很好，这就是控制器的用途。
现在根据上述内容，我说我可以很愉快地构建我的应用程序，没有任何重大问题。 然而，在我正常浏览代码示例等的同时，我经常发现有很多其他方法可供不同的开发人员用来完成我上面所做的基本操作，并且我想要解释它们都适合在一起。
我经常看到提到“使用你的存储库做等等”。我确实使用了“有时”的存储库，但这主要是为了模型查询，我知道我将来会重复使用它总是会变成一点点垃圾场。 这里的最佳做法是什么？
我也看到提到“接口”和“服务层”我在这里完全迷失了……大多数例子对我来说似乎只是添加了越来越多的步骤来实现相同的目标。 它们是如何使用的？
我不能说这是最好的做法，但这就是我使用的，为什么，我们在这里：
1.存储库。
它们的结构如下：
有三个基本接口， IRead<> ， IReadCreate<>和IReadCreateDelete<> 。
interface IRead { T FindOne(int id); IQueryable GetOne(int id); IQueryable FindAll(Expression> predicate); } interface IReadCreate : IRead { T Create(); void Create(T entity); } interface IReadCreateDelete : IReadCreate { void Delete(int id); void Delete(T entity); void DeleteWhere(Expression> predicate); }
所有其他接口如下所示：
interface ICategoriesRepository : IReadCreate { IQueryable GetAllActive(); }
所有这些都为它们所依赖的数据源提供了额外的有用function。 这意味着，我无法访问我的实现存储库中的其他类型存储库。 这应该在服务上完成。 （往下看。）
这种方法的主要目标是显示调用代码（来自另一个程序集，因为我的所有存储库，服务和其他契约都在单独的DLL项目中定义（作为接口））它能做什么（比如读取和创建项目）以及什么它不能做（比如删除项目）。
2.服务
服务和实施业务逻辑的最佳方式。 他们应该实施所有重要的逻辑方法。 为了实现这种实现，他们需要一些存储库依赖，并且它来自Dependency Injector 。 我更喜欢使用Ninject ，因为它允许我注入依赖属性，如下所示：
internal class CategoriesService : ICategoryService { public ICategoriesRepository CategoriesRepository { get; set; } public IWorkstationsRepository WorkstationsRepository { get; set; } // No constructor injection. I am too lazy for that, so the above properties // are auto-injected with my custom ninject injection heuristic. public void ActivateCategory(int categoryId) { CategoriesRepository.FindOne(categoryId).IsActive = true; } }
服务的目标是从控制器和存储库中消除业务逻辑。
3. ViewModels
很酷的事情，正如你所说的那样，但原因在于你为什么在他们自己建造它们是我无法得到的东西。 我正在使用automapper （带有可查询的扩展），这允许我创建这样的视图：
假设我有一个需要IEnumerable模型的视图 。 我所做的是：
public class FooController : Controller { public IMappingEngine Mapping { get; set; } // Thing from automapper. public ITicketsRepository TicketsRepository { get; set; } public ViewResult Tickes() { return View(TicketsRepository.GetAllForToday().Project(Mapping) .To().ToArray(); } }
而已。 对存储库的简单调用，它调用底层数据源（另一种模式。我不会写它，因为它的抽象仅用于测试。），这使得调用数据库（或任何你实现IDataSource ）。 TicketViewModel自动将Ticket映射到TicketViewModel和表单数据库I我只检索ViewModel列所需的唯一列，包括单个请求中的交叉表 。
结论
还有很多话要说，但我希望这会给你一些思考的东西。 我使用的所有模式和程序是：
- 自动映射（映射）;
- Ninject（dependency injection）;
- 存储库（数据访问）;
- 数据源（数据来自……井……来自数据源）;
- 服务（数据交互）;
- ViewModels（数据传输对象）;
- 也许其他我会编辑添加的东西。
当我开始阅读你的post时，我在想，也许你正在寻找的是对SOLID原则的理解。 最后提到接口和服务层。 有趣。
有很多文章庆祝SOLID和DRY的圣杯（很多人都没有理解DRY倡导者真正提出的建议）。 但是.NET世界中的一般想法，不是去aspx中自动生成的Page_Load，而是开始输入所有内容，直到页面执行它应该做的事情。 MVC来救援。
你说每个视图都有一个模型。 我会说那个声音。 即使两个模型相同，它们也只是相同，不一样。 例如：NewsItem不是EventItem。 如果你想扩展一个，它不应该影响另一个。
然后，您继续说您正在视图模型中生成模型。 这听起来倒退了。 但是你说你是这样做的，以保持你的控制器清洁。 好！ 您的思维方式缺少的是服务。
您要做的是将实际执行任何类型工作的所有代码移动到服务中。 服务可以基于方面，或基于特征，或者为什么不是控件。 现在看一个Web项目，我看到：VisitorService，NewsfeedService，CalendarService，CachingService，MainMenuService，HeaderService，FooterService等等无限制地。
在这种情况下，控制器仅负责向模型询问执行某些工作的服务（或服务）。 然后将该模型转发到视图。
一旦您将“业务逻辑”转换为服务，您就可以轻松地将IoC（控制反转）应用于您的项目，如果这让您满意的话。 我还没有对IoC投票。 我有可怕的好处并不像广告那么好，你可以确保没有代码臃肿。 但IoC确实要求你在编码前思考。
关于IoC的一个非常简单的教程，我推荐Ninject。 它不仅有Ninjas，还有武士，剑和手里剑。 这比汽车和动物要凉爽得多。
https://github.com/ninject/ninject/wiki/Dependency-Injection-By-Hand
控制器：
理论上，您的控制器应该只处理“数据”。 将信息从一个地方移动到另一个地方。
小例子：
- 控制器接收带有一些参数的请求“GetMessage”。
- 将此数据发送到服务层。 在服务层中，您正在访问存储库返回消息。
- Cntroller收到此消息（或者如果没有null）并决定是否重新发送收到的消息或者可能存在错误，并且应该以某种方式通知用户。
所有“理论上”的业务逻辑都应该落后于某个服务层。 这样你就可以轻松测试一切。 控制器中的逻辑使得一些测试更加困难。
接口：
基于接口的设计现在非常流行。 特别是所有IOC Containers处理dependency injection。 但是，如果您从这个概念开始，请不要理会这些关键字。 如果您知道Repository模式，那么首先尝试使用IRepository接口，而不是通过具体类访问存储库，使用IRepository。 （只需将控制器中的字段从Repository更改为IRepository）。
一般关于接口
您将在更复杂的场景中看到界面的好处，但有一种技术可以向您展示这种方法的所有荣耀。 unit testing+模拟。