MVC模式差异

mun*_*kee 11 c# model-view-controller interface

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

目前,我倾向于使用视图模型模式构建我的Web应用程序.对于每个视图,我都有一个视图模型.我喜欢这种方法纯粹是因为模型中不需要这么多垃圾,我可以在这里使用一些基本的数据注释.

我现在也在视图模型中构建我的视图模型(不确定这是否正确?)这样我就可以让控制器尽可能简单.

有时候我发现自己在控制器中添加了很多逻辑,我认为这对我来说也很好,这就是控制器的用途.

现在根据上述内容,我说我可以很愉快地构建我的应用程序,没有任何重大问题.然而,在我正常浏览代码示例等的同时,我经常发现有很多其他方法可供不同的开发人员用来完成上面我正在做的事情,并且我想要解释它们都适合在一起.

我经常看到提到"使用你的存储库来做等等".我确实使用了"有时"的存储库,但这主要是为了模型查询,我知道我将来会重复使用它总是会变成一点点垃圾场.这里的最佳做法是什么?

我也看到提到"接口"和"服务层"我在这里完全迷失了......对我来说,大多数例子似乎只是添加了越来越多的步骤来实现相同的目标.它们是如何使用的?

Age*_*ire 5

我不能说这是最好的做法,但这就是我使用的,为什么,我们走了:


1.存储库.

它们的结构如下:

有三个基本接口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);
}
Run Code Online (Sandbox Code Playgroud)

所有其他接口如下所示:

interface ICategoriesRepository : IReadCreate<Category>
{
    IQueryable<Category> GetAllActive();
}
Run Code Online (Sandbox Code Playgroud)

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

这种方法的主要目标是显示调用代码(来自另一个程序集,因为我的所有存储库,服务和其他契约都在单独的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;
    }
}
Run Code Online (Sandbox Code Playgroud)

服务的目标是从控制器和存储库中消除业务逻辑.


3. ViewModels

很酷的事情,正如你所说的那样,但原因在于你为什么在他们自己建造它们是我无法得到的东西.我正在使用automapper(具有可查询的扩展名),这允许我创建这样的视图:

假设我有一个需要模型的视图IEnumerable<TicketViewModel>.我所做的是:

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();
     }
}
Run Code Online (Sandbox Code Playgroud)

而已.对存储库的简单调用,它调用底层数据源(另一种模式.我不会写它,因为它的抽象仅用于测试.),这使得调用数据库(或任何你实现的IDataSource<T>).Automapper自动映射Ticketto TicketViewModel和form数据库我检索我的ViewModel列所需的唯一内容,包括单个请求中的交叉表.


结论

还有很多话要说,但我希望这会给你一些思考的东西.我使用的所有模式和程序是:

  1. 自动映射(映射);
  2. Ninject(依赖注入);
  3. 存储库(数据访问);
  4. 数据源(数据来自..井......来自数据源);
  5. 服务(数据交互);
  6. ViewModels(数据传输对象);
  7. 也许其他我会编辑添加的东西.