c# - MVC 模式差异

Question

我只需要一些指向我可以阅读的文章的链接，或者一些关于 MVC (C#) 中使用的不同模式的基本解释。

目前我倾向于使用 View 模型模式来构建我的网络应用程序。对于每个 View ，我都有一个 View 模型。我喜欢这种方法纯粹是因为模型中可能有很多不需要的垃圾，我可以在这里使用一些基本的数据注释。

我现在还在 View 模型本身内构建我的 View 模型(不确定这是否正确？)这样我就可以让我的 Controller 尽可能简单。

但有时我发现自己在我的 Controller 中添加了很多逻辑，我认为这对我来说也很好，这就是 Controller 的用途。

现在，正如我所说，基于以上内容，我可以非常愉快地构建我的应用程序，而不会出现任何重大问题。然而，在我正常浏览代码示例等的同时，我经常发现不同的开发人员使用了许多其他方法来完成我上面正在做的事情，我想解释一下它们都是如何组合在一起的。

我经常看到提到“使用你的存储库来做等等”。我确实“有时”使用存储库，但这主要用于模型查询，我知道我将来会重新使用它并且它总是变成一个有点像垃圾场。这里的最佳做法是什么？

我还看到提到的“接口(interface)”和“服务层”我完全迷失在这里.. 大多数例子对我来说似乎只是添加越来越多的步骤来实现相同的目标。如何/为何使用它们？

Answer 1

我不能说这是最佳实践，但这是我使用的，为什么，我们开始吧:

---

1。存储库。

它们的结构是这样的:

基本接口(interface)一共有三个，IRead<> , IReadCreate<>和 IReadCreateDelete<> .

interface IRead<T>
{ 
    T FindOne(int id);
    IQueryable<T> GetOne(int id);
    IQueryable<T> FindAll(Expression<Func<T, bool>> predicate);
}

interface IReadCreate<T> : IRead<T>
{ 
    T Create();
    void Create(T entity);
}

interface IReadCreateDelete<T> : IReadCreate<T>
{ 
    void Delete(int id);
    void Delete(T entity);
    void DeleteWhere(Expression<Func<T, bool>> predicate);
}

所有其他界面如下所示:

interface ICategoriesRepository : IReadCreate<Category>
{
    IQueryable<Category> GetAllActive();
}

而且它们都在它们所依赖的数据源上提供了额外的有用功能。这意味着，我无法访问我的实现存储库中的其他类型存储库。这应该在服务上完成。 (看下面。)

这种方法的主要目标是显示调用代码(来自另一个程序集，因为我所有的存储库、服务和其他契约都在单独的 DLL 项目中定义(作为接口(interface)))它可以做什么(比如读取和创建项目) 以及它不能做什么(例如删除项目)。

---

2。服务

服务和实现业务逻辑的最佳方式。他们应该实现所有重要的逻辑方法。为了实现这种实现，他们需要一些存储库依赖性，这就是 Dependency Injector。 .我更喜欢使用 Ninject，因为它允许我像这样注入(inject)依赖属性:

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;
    }
}

服务的目标是从 Controller 和存储库中消除业务逻辑。

---

3。 View 模型

很酷的事情，正如你所说的，但原因是为什么你自己建立他们是我无法得到的。为此，我正在使用 automapper(及其可查询的扩展)，它允许我创建这样的 View :

假设我有一个需要 IEnumerable<TicketViewModel> 的 View 模型。我所做的是:

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<TicketViewModel>().ToArray();
     }
}

就是这样。对存储库的简单调用，它会调用底层数据源(另一种模式。我不会写它，因为它的抽象仅用于测试。)，它会调用数据库(或任何你实现的 IDataSource<T> )。 Automapper 自动映射 Ticket至 TicketViewModel并形成数据库，我检索我的 ViewModel 列唯一需要的，包括单个请求中的交叉表。

---

结论

还有很多话要说，但我希望这能给你一些思考。我使用的所有模式和程序是:

1. Automapper(映射)；
2. Ninject(依赖注入(inject))；
3. 存储库(数据访问)；
4. 数据源(数据从……嗯……从数据源读取)；
5. 服务(数据交互)；
6. ViewModels(数据传输对象)；
7. 也许我会编辑添加其他内容。