ASP.NET MVC与服务层和存储库层，应该在哪里接口定义？ [英] ASP.NET MVC with service layer and repository layer, where should the interfaces be defined?

问题描述

我在确定为具有储存库层和服务层的.NET MVC应用一个相当简单的层状结构的过程。我已经发现了一些相当清晰和简单的例子，特别是<一个href=\"http://www.asp.net/mvc/tutorials/older-versions/models-%28data%29/validating-with-a-service-layer-cs\">www.asp.net,和一些问题和答案在这里，但我寻找的东西比较简单了一点，适合小型应用，但使用不同的项目，在整个的想法。我联系到上面的例子有资源库和服务为在型号命名空间中的类。这是不够清晰的分离对我来说，能够正确地说明了它。

I am in the process of determining a fairly simple layered architecture for a .NET MVC application that has a repository layer and a service layer. I have found some fairly clear and simple examples, notably www.asp.net, and some questions and answers here, but I am looking for something that is a little simpler, suitable for small applications, but that uses different projects, to get the idea across. The example I linked to above has the repository and service as classes in the Models namespace. That just isn't enough of a clear separation for me to be able to illustrate it properly.

我有一个实现了接口IRepository库单独的项目。没有为实现IService和接受一个I​​Repository（构造函数注入）的服务项目separarate。服务实现IService。这是足以让这个例子控制器实例化的服务，无需IoC容器，只是还没有。把它看成是一个中间步骤，以了解最佳建筑实践，即逐步建立包括依赖注入甚至更多层的序列的一部分。

I have a separate project for the repository that implements interface IRepository. There is a separarate project for the Service that implements IService and takes an IRepository (constructor injection). The Service implements IService. It is enough for this example that the controller instantiate the service, no need for an IoC container just yet. Think of it as an intermediate step to understanding best architectural practices, part of a sequence that builds progressively to include dependency injection and possibly more layers.

现在的问题是，在那里我应该定义IRepository和IService？无论是服务和存储库的项目需要引用他们，当然。它似乎很清楚那么，他们应该由服务和存储库的项目都引用另一个项目中定义。如果是这样，将良好的命名规范是什么？喜欢的东西XXXXContracts？

The question is, where should I define IRepository and IService? Both the service and repository projects need to reference them, of course. It seems clear then that they should be defined in another project referenced by both the service and repository projects. If so, what would a good naming convention be? Something like XXXXContracts?

同样，对于presentation，服务和存储库层之间传递的数据模型，它是可以接受的所有图层引用一个单独的项目叫XXXXModels？据我所知，在某些情况下，服务和存储库层之间传递的模型可以从这些服务层和presentation层之间传递不同，但原理是一样的。

Likewise, for the data models passed between the presentation, service and repository layers, is it acceptable to have a separate project called XXXXModels referenced by all the layers? I understand that in some cases the models passed between the service and repository layer can differ from those passed between the service layer and the presentation layer, but the principle is the same.

我已经在这里找到答案，类似的问题，但他们往往涉及比我在这里提出了一个更复杂的结构。我期待实现一个非常简单和干净的，可以看作是上述引用数据层和控制器有业务逻辑的两步两层的例证，这就是全部。我知道有一个强大和有效的论据直要到全面爆发的最佳做法，但不是每个人都适合使这一跳一气呵成。

I have found answers to similar questions here, but they tend to involve a more complicated architecture than what I have outlined here. I'm looking to achieve a really simple and clean illustration of the two layers that can be seen as a step or two above referencing the data layer and having business logic in the controllers, that's all. I know there is a strong and valid argument for going straight to the full-blown best practice, but not everyone is suited to making that jump in one go.

推荐答案

这是我一直问自己为好。一个迫切的问题我一直有与你相似;

Introduction

This is something I've asked myself as well. One burning question I always have is similar to yours;

将良好的命名规范是什么？

what would a good naming convention be?

我应该如何命名的东西呢？他们应该在文件夹或项目中去？

How should I name things? Should they go in folders or projects?

搜索周围我怀疑之后，答案是的它并不真正的问题的。最重要的是，你解决方案有一些合理的架构和大家尽量遵循好的做法，如 SOLID 。

After searching around I suspect the answer is that it doesn't really matter. What's important is that you solution has some sensible architecture and that you try to follow good practices such as SOLID.

在这个话题我的ASP.NET MVC的英雄是杰弗里巴勒莫，的史蒂夫·史密斯和吉米·博加德。

My ASP.NET MVC heroes on this topic are Jeffrey Palermo, Steve Smith and Jimmy Bogard.

杰弗里巴勒莫讨论的旧观念相结合而带来在一起，并赋予它的视觉刺激名洋葱架构（推荐阅读）。杰弗里显示了良好的方法，在哪里放东西的问题。他解释说，在你的应用程序的中心（或顶部）你有你的核心。这一层是你应该把诸如 IRepository 接口和 IService 。

Jeffrey Palermo discusses a combination of old ideas but brings them together and gives it the visually stimulating name of Onion Architecture (a recommended read). Jeffrey shows a good approach to the problem of where to put things. He explains that at the centre (or top) of your application you have your Core. This layer is where you should put interfaces such as IRepository and IService.

几乎所有的接口都应该在核心和其他一切（其它项目）可以去所有参考的核心。通过这种方式知道的一切应用的骨骼结构不知道的实施细节。

Almost all of your interfaces should go in the core and everything else (other projects) can all reference the core. This way everything knows the skeletal structure of the application without knowing the implementation details.

试着让你的UI层参考尽可能少（在合理范围内）。在我的应用我的一个UI（MVC）层只引用核心。它需要一切都注入其与依赖注入。

Try to have your UI layer reference as little as possible (within reason). In one of my applications my UI (MVC) layer only references the Core. Everything it needs is injected into it with Dependency Injection.

史蒂夫·史密斯介绍洋葱架构，并与 MVC解决方案演示类似的想法最佳实践：一个解决问题的解决方案

Steve Smith discusses Onion Architecture and similar ideas with demonstrations in MVC Solution Best Practices: A solution to the solution problem

在我的MVC解决方案，我有一个这样的典型结构：

In my MVC solutions I have a typical structure like this:

• MyProject.Core


• MyProject.Domain


• MyProject.DependencyInjection


• MyProject.Infrastructure


• MyProject.Web


• MyProject.Tests

在核心包含我的接口。它通常被分为般的服务，模型，领域，库等文件夹。

The Core contains my interfaces. It is usually divided up into folders like Services, Models, Domain, Repositories and so on.

在域层只引用核心，包含我的实现。它提供了很多具体的类中的核心域抽象。它涉及了很多的业务逻辑，处理，指挥处理，管理类，具体服务实现等等。我认为这是一个相当内层，所以它尽可能少引用越好。

The Domain layer references only the core and contains my implementation. It provides a lot of the concrete classes for the domain abstraction in the core. It deals with a lot of business logic, processing, command handling, manager classes, concrete service implementations and so on. I consider it a fairly inner-layer and so it references as little as possible.

在 DependencyInjection 层包含我选择的DI包/框架和实施细则。我认为它的外层;类似的用户界面或基础设施，所以它的确定，如果它引用了很多。这是没有必要为这层是一个独立的项目，很多人会告诉你不要这样做。没关系;做的项目的复杂程度是什么在起作用。我喜欢我的DI是它自己的事情。它是如此分开的好处是，我可以用一个不同的替换DI框架，事情就可以了。无层引用DI项目。

The DependencyInjection layer contains my chosen DI package/framework and implementation details. I consider it an outer layer; similar to UI or Infrastructure and so it's ok if it references a lot. It's not necessary for this layer to be a separate project and many people will tell you not to do this. That's ok; do what works for the complexity of your project. I like my DI to be its own thing. The good thing about it being so separate is that I could replace the DI framework with a different one and things would be fine. No layers reference the DI project.

在基础设施层包含记录的信息，电子邮件和数据访问。它将包含选择我的 ORM 。这不是业务逻辑的东西，它不是UI的东西。这是把事情做好我的解决方案的铁路。它在外层上，但它只是引用的核心。

The Infrastructure layer contains information about logging, emailing and data access. It will contain my ORM of choice. It's not business-logic stuff and it's not UI stuff. It's the railroad of my solution to get things done. It's on the outer layer but it only references the Core.

在网站层是我的MVC项目和只引用核心。

The Web layer is my MVC project and only references the Core.

我已经找到答案，这里类似的问题，但他们往往涉及比我在这里提出了一个更复杂的结构。

I have found answers to similar questions here, but they tend to involve a more complicated architecture than what I have outlined here

这是一个很好的点。重要的是要记住你的问题的复杂性是非常重要的。但不要被很好的解决方案的做法予以制止。我的解决方案和洋葱建筑不一定是非常复杂的，真的不膨胀您的解决方案。他们只是让事情分开。

It's a good point. It's important to keep in mind the complexity of your problem. But don't be deterred by good solution practices. My solution and Onion Architecture are not necessarily very complex and don't really bloat your solution. They just keep things separate.

在进化项目结构，吉米·博加德的事情正在谈过于复杂。如果我说的话似乎太复杂，请按照吉米的建议，并把它都在一个项目（你的UI层）。没关系 - 只要它适合你。

In Evolutionary Project Structure, Jimmy Bogard talks about things being over-complex. If what I've said seems too complex, follow Jimmy's advice and put it all in the one project (your UI layer). That's ok - as long as it suits you.

记住把我的解决方案，只是作为一个想法 - 要考虑的事情;我的做法是试图遵循的最佳明智的建议，但我敢肯定，我只成功了那么多;我可以（而且必须）仍然提高。

Remember to take my solution only as an idea - something to consider; my approach is an attempt to follow sage advice from the best, but I'm sure I've only succeeded so much; I can (and must) still improve.

这篇关于ASP.NET MVC与服务层和存储库层，应该在哪里接口定义？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！