MVC模式差异我只需要一些我可以阅读的文章链接或者一些关于MVC(C#)中使用的不同模式的基本解释。目前，我倾向于使用视图模型模式来构建我的Web应用程序。对于每个视图，我都有一个视图模型。我喜欢这种方法纯粹是因为我不需要模型中的垃圾那么多，而且我可以在这里使用一些基本的数据注释。我现在也在viewmodel中构建我的viewmodel（不确定这是否正确？）以便我可以使控制器尽可能简单。有时我发现自己在我的控制器中添加了很多逻辑，我认为这对我来说也很好，这就是控制器的用途。现在基于以上内容，我想说我可以愉快地构建我的应用程序而不会出现任何重大问题。然而，当我通常浏览代码示例等时，我经常发现不同的开发人员可以使用许多其他方法来完成我上面所做的基本事情，我想解释一下它们都是相辅相成的。我经常看到提到“使用您的存储库来做等”。我确实“有时”使用存储库，但这主要用于模型查询，而且我知道我将来会重用它，它总是会变成一个小垃圾堆。这里的最佳做法是什么？我还看到提到“接口”和“服务层”我在这里完全迷路了……在我看来，大多数示例只是添加了越来越多的步骤来实现相同的目标。它们是如何使用的？我不能说这是最佳实践，但这是我使用的，为什么，我们在这里：1.存储库。它们的结构如下：共有三个基本接口，IRead、IReadCreate和IReadCreateDelete。接口IRead{TFindOne(intid);IQueryableGetOne(intid);IQueryableFindAll(表达式>谓词);}接口IReadCreate:IRead{TCreate();无效创建（T实体）；}接口IReadCreateDelete:IReadCreate{voidDelete(intid);voidDelete(T实体);voidDeleteWhere(表达式>谓词);}所有其他接口看起来像这样：interfaceICategoriesRepository:IReadCreate{IQueryableGetAllActive();所有这些都为它们所依赖的数据源提供了额外的有用功能。这意味着，我无法访问我的实现存储库中的其他类型存储库。这应该在服务上完成。（见下文。）此方法的主要目标是显示调用代码（来自另一个程序集，因为我所有的存储库、服务和其他契约都在单独的DLL项目中定义（作为接口））它可以做什么（比如读取和创建项目）以及它不能做什么（比如删除项目）。2.服务服务和实现业务逻辑的最佳方式。他们应该实施所有重要的逻辑方法。对于此实现，他们需要一些存储库依赖项，它来自DependencyInjector。我更喜欢使用Ninject，因为它允许我像这样注入依赖属性：放;}公共IWorkstationsRepositoryWorkstationsRepository{得到;放;}//没有构造函数注入。我太懒了，所以上面的属性//是用我的自定义ninject注入启发式自动注入的。publicvoidActivateCategory(intcategoryId){CategoriesRepository.FindOne(categoryId).IsActive=true;}}服务的目标来自控制器并消除存储库中的业务逻辑。3.ViewModels是很酷的东西，正如你所说，但你自己构建它们的原因是我无法理解的。我正在使用automapper（具有可查询扩展），它允许我创建这样的视图：假设我有一个需要IEnumerable模型的视图。我所做的是：publicclassFooController:Controller{publicIMappingEngineMapping{get;放;}//来自自动映射器的东西。公共ITicketsRepositoryTicketsRepository{得到;放;}publicViewResultTickets(){returnView(TicketsRepository.GetAllForToday().Project(Mapping).To().ToArray();}}就是这样。对调用基础数据源的存储库的简单调用（另一种模式。我不会写它，因为它的抽象只是为了测试。)，这会调用数据库（或您实现IDataSource的任何地方）。TicketViewModel自动将Ticket映射到TicketViewModel并形成数据库我只检索ViewModel列所需的唯一列，包括单个请求中的交叉表。结论还有很多话要说，但我希望这能给你一些思考。我使用的所有模式和程序是：Automap（映射）；Ninject（依赖注入）；存储库（数据访问）；数据源（数据来自...嗯...来自数据源）；服务（数据交互）；ViewModels（数据传输对象）；也许我会编辑添加其他内容。当我开始阅读您的帖子时，我在想也许您正在寻找的是对SOLID原则的理解。最后，提到了接口和服务层。有趣的。有很多文章庆祝SOLID和DRY的圣杯（很多人不明白DRY倡导者真正提出的是什么）。但是.NET世界的一般想法是开始键入所有内容，直到页面执行它应该执行的操作，而不是转到aspx中自动生成的Page_Load。MVC来拯救。你说每个视图都有一个模型。我会说那个声音。即使两个模型相同，它们也只是相同，而不是相同。例如：NewsItem不是EventItem。如果你想延长一个，它不应该影响另一个。然后你继续说你在视图模型中生成模型。这听起来很倒退。但是你说你这样做是为了保持你的控制器干净。好的！您的心态中缺少的是服务。您所做的是将实际执行任何类型工作的所有代码移动到服务中。服务可以是基于方面的，或者是基于特征的，或者为什么不是控制。现在看一个web项目，看到：VisitorService、NewsfeedService、CalendarService、CachingService、MainMenuService、HeaderService、FooterService等等没有限制。在这种情况下，控制器只负责向模型询问执行某些工作的服务（或多个服务）。然后将该模型转发给视图。将“业务逻辑”转换为服务后，如果适合，您可以轻松地将IoC（控制反转）应用于您的项目。我还没有投票给国际奥委会。我有一个可怕的好处，它没有宣传的那么好，而且你可以确定没有代码膨胀。但是IoC确实需要您在编码之前进行思考。对于一个非常简单的IoC教程，我推荐Ninject。它不仅有忍者，还有武士、刀剑和手里剑。这比汽车和动物要酷得多。https://github.com/ninject/ninject/wiki/Dependency-Injection-By-HandControllers：理论上，您的控制器应该只处理“数据”。将信息从一个地方转移到另一个地方。小例子：控制器收到带有一些参数的请求“GetMessage”。将此数据发送到服务层。在服务层中，您正在访问存储库返回消息。Cntroller收到此消息（如果没有则为null）并决定是否重新发送收到的消息或者可能有错误并且应该以某种方式通知用户。所有“理论”业务逻辑都应该在某个服务层之后。这样你就可以轻松地测试一切。控制器中的逻辑使一些测试更加困难。接口：基于接口的设计现在非常流行。特别是所有IOC容器都处理依赖注入。但是，如果您从这个概念开始，请忽略这些关键字。如果您了解Repository模式，那么首先尝试使用IRepository接口，而不是通过具体类访问存储库，而是使用IRepository。（只需将控制器中的字段从Repository更改为IRepository）。关于一般接口您将在更复杂的场景中看到接口的好处，但是有一种技术可以向您展示这种方法的所有优点。单元测试+模拟。以上就是《C#学习教程：MVC模式差异分享》的全部内容。如果对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
