MVC模式差异 [英] MVC pattern differences

问题描述

我只需要一些链接到我可以阅读的文章或关于MVC（C＃）中使用的不同模式的一些基本解释。

I just need a few links to articles I can read up on or some basic explanations regarding the different patterns used in MVC (C#).

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

At present I tend to build my web apps using a view model pattern. For every view I have one view model. I like this approach purely because there can be so much junk that is not needed from the model and I can use some basic data annotations here.

我现在也构建了我的viewmodels在视图模型本身内（不确定这是否正确？）这样我就可以让我的控制器尽可能简单。

I also now construct my viewmodels within the view model itself (Unsure if this is correct?) so that I can keep my controllers as simple as possible.

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

There are times however I have found myself adding in a lot of logic within my controller, I would assume this is fine also as to me that is what the controller is there for.

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

Now based on the above as I said I can quite happily build my apps without any major issues. However whilst doing my normal browsing of code examples etc I often find that there are so many other ways out there used by different developers to do essentially what I am doing above and I would like an explanation of they all fit together.

我经常看到提到使用你的存储库做blah blah..我确实使用repositorys有时但这主要是为了模型查询，我知道我将重新使用未来它总是变成一个倾销的地方。这里的最佳做法是什么？

I often see mentioned "use your repository to do blah blah".. I do use repositorys "sometimes" but this is mainly for model querying that I know I will re-use in the future and it always turns in to a bit of a dumping ground. What is best practice here?

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

I also see mentioned "interfaces" and "service layers" I am totally lost here.. most examples to me seem to just be adding more and more steps to achieve the same goal. How/why are they used?

推荐答案

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

I can't say this is the best practice, but this is what I use, and why, and here we go:

它们的结构如下：

有三个基本接口， IRead<> ， IReadCreate<> 和 IReadCreateDelete<> 。

There are three basic interfaces, IRead<>, IReadCreate<> and 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);
}

所有其他界面如下所示：

The all other interfaces look like this:

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

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

And all of them provides additional usefull functionality on the data source they depend on. It means, I cannot reach other typed repositories in my implementation repository. That should be done on Services. (Look below.)

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

The main goal of this approach is to show the calling code (from another assembly, because all my repositories, services and other contracts are defined (as interfaces) in separate DLL project) what it can do (like reading and creating items) and what it cannot do (like deleting items).

服务和实施业务逻辑的最佳方式。他们应该实施所有重要的逻辑方法。为了实现这种实现，他们需要一些存储库依赖，并且它来自依赖注入器。我更喜欢使用 Ninject ，因为它允许我注入这样的依赖属性：

Services and best way to implement your business logic. They should implement all your vital logic methods. To achive that kind of implementation they will need some repositories depency, and here it comes the Dependency Injector. I prefer to use Ninject, because it allows me to inject dependency properties like this:

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

服务的目标是从控制器中消除业务逻辑来自存储库。

The goal of services is to eliminate business logic from controllers and from repositories.

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

Cool thing, as you told, but the reason is why are you building them up in theirselves is the thing I can't get. I am using the automapper for that (with its queryable extensions), which allows me to create views like this:

假设我有一个查看，需要 IEnumerable< TicketViewModel> 模型。我所做的是：

Let's say I have a view which needs an IEnumerable<TicketViewModel> model. What I do is:

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 和表单数据库I retrive 唯一需要的对于我的ViewModel列，包括单个请求中的交叉表。

That's it. Simple call to repository, which makes calls to underlying data source (another pattern. I wont write about it, because its abstraction is needed only for testing.), which makes calls to database (or whatever you implement IDataSource<T>). Automapper automappically maps the Ticket to TicketViewModel and form database I retrive the only needed for my ViewModel columns, including the cross-table in a single request.

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

There are much to say more, but I hope this will give you some food for thought. All the patterns and programs I use are:

1. Automapper（mapping）;


2. Ninject （依赖注入）;


3. 存储库（数据访问）;


4. 数据源（数据从..井中读取...来自数据源）;


5. 服务（数据交互）;


6. ViewModels（数据传输对象）;


7. 也许别的什么我' ll编辑添加。

1. Automapper (mapping);
2. Ninject (dependency injection);
3. Repositories (data access);
4. Data Source (data reads from .. well.. from data source);
5. Services (data interactivity);
6. ViewModels (data transfer objects);
7. Maybe something else I'll edit to add about.

这篇关于MVC模式差异的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！