我试着写一些业务逻辑，我的应用程序。在我的应用程序的核心是从数据库优先模式EF生成的实体。我从的.edmx部分分离生成的类（.TT文件）。

I'm trying to write some business logic for my app. At the core of my app are EF generated entities from Database First model. I have separated generated classes (.tt file ) from .edmx part.

我想找到最好的地方，把我的业务逻辑，而的问题是，业务逻辑需要一些复杂的依赖关系，例如，需要记录，调用一些web服务，或使纯SQL调用数据库中。 正因为如此，我不能只使用新的（）内的功能和创建硬依赖关系，但我想以某种方式抽象出来，从他们身上，以下DI原则。

I want to find the best place where to put my business logic, but the problem is, that business logic requires some complicated dependencies, for example, needs logging, calls some WebService, or makes pure SQL calls to DB. Because of that, I can't just use new() inside functions and create hard dependencies, but I want to somehow abstract away from them, following DI principles.

public class Person
{
    public Person(IDbCaller dbCaller, IWebServiceCaller webServiceCaller) { }
}

我的第一个赌注是使用部分类，扩展EF类。

My first bet was to use partial classes, that extend EF classes.

不过，读了一些文章之后，我现在想，注入依赖到EF类是不是一个好主意：

But after reading some articles, I am now thinking that injecting dependencies into EF classes is not a good idea:

Why不要使用IoC容器来解决依赖于实体/业务对象？

的http://lostechies.com/jimmybogard/2010/04/14/injecting-services-into-entities/

那么，我应该在哪里把这个逻辑呢？我同意，在EF实体依赖是不好的，但我不能真正找到解决方案。逻辑需要在某个地方。 我看到几个选项/问题：

So, where should I put this logic? I agree, that dependencies on EF entities are bad, but I cant really find solutions. Logic needs to be somewhere. I see a few options/questions:

1）把业务逻辑（需要依赖）内的服务层。这可能会导致贫血的域模型，但也许服务层是正确的地方这样的逻辑，这需要依赖？

1) Put business logic (that requires dependencies) inside Service layers. This could lead to Anemic Domain Model, but maybe Service layers are the right place for this kind of logic, that requires dependencies?

2）创建一些国王或包装/工厂类，我需要调用每次查询返回的实体，这样我就可以换实体的商业逻辑。

2) Create some king or Wrapper/Factory classes, that I need to call every time query returns entities, so I can wrap entity with business logic.

3）将这一逻辑一些其他类的内部，即采取实体作为函数参数。

3) Put that logic inside some other classes, that take entity as a function parameter.

什么是这一些好的，常见的做法是什么？

推荐答案

现在的问题是，你是混合两种相反的设计：DDD和贫血模型

The problem is that you are mixing two opposite designs: DDD and anemic model.

如果您使用DDD

在应用程序中的类必须是域对象（实体和值对象）。你必须履行这些承诺没有考虑如何将存储在数据库中（或者你使用任何后端）。当你完成的域对象设计你实现一个EF模型，满足您的域对象的持久性需求。所以，在很多情况下会出现不域对象（实体和值对象）和EF实体之间的直接映射。

The classes in your application must be domain objects (entities and value objects). You must implement them without thinking how they will be stored in the database (or whatever backend you use). When you finish the domain object design you implement an EF model which satisfies the persistency needs of your domain objects. So, in many cases there will be not direct mapping between the domain objects (entities and value objects) and an EF entity.

即。在此实现你的域对象将在某个时候来存储数据。你就会有实现的EF模型，支持存储这些数据。

I.e. in this implementation your domain object will have to store data at some point. And you'll have to implement an EF model that supports storing this data.

至于相关性，在这种情况下，他们会在你的域对象，而不是在你的EF实体。然后，你可以使用普通模式（工厂，DI）来创建你的域模型。也许这种依赖一个将被存储库与EF实现。

As to the dependencies, in this case they'll be in your domain objects, not in your EF entities. Then you can use the usual patterns (Factory, DI) to create your domain models. Probably one of this dependencies will be Repositories implemented with EF.

如果您使用贫血模型

首先，我必须说，有这样的许多成功的实现，即使福勒说，这是一个反模式。我不会同意或不同意福勒，但我必须揭露的事实。

First I must say that there are many succesful implementations of this kind, even if Fowler says it's an anti-pattern. I'm not going to agree or disagree with Fowler, but I must expose the facts.

如果您实现使用贫血模型的应用程序，你可以设计你的EF（贫血）模型开始，然后实现所有的业务逻辑的服务类。

If you implement your application using an anemic model, you can start by designing your EF (anemic) model, and then implement all the business logic in service classes.

的大错

这是贫血模型通常是一个数据中心的设计的结果。在福勒的话：我不知道为什么这种反模式是如此普遍。我怀疑这是由于很多人谁没有真正曾与一个合适的领域模型，尤其是当它们来自数据的背景的所以，如果你做这个启动：在我的应用程序的核心在EF生成从数据库首先模型实体。的你就必须实现纯DDD（的你可以阅读这篇文章，以了解为什么）

An anemic model is usually the result of a data-centric design. In the words of Fowler: I don't know why this anti-pattern is so common. I suspect it's due to many people who haven't really worked with a proper domain model, particularly if they come from a data background. So, if you start by doing this: At the core of my app are EF generated entities from Database First model. you'll have trouble to implement pure DDD (you can read this article to understand why)

回答您的意见：

1），这是一个贫血的模型

1) this is an anemic model

2）你从存储的数据域对象预期的直接映射。您会收到一个实体，并希望将功能添加到它。没了！你的域对象必须使用EF请求持久化数据，而不是倒过来！

2) you're expecting a direct mapping from stored data to domain objects. You receive an entity and want to add functionality to it. Nope! Your domain object has to use EF to request the persisted data, and not the other way round!

3），这是1）再次

您可以找到这篇文章很有意思：The血虚域模型是没有反模式，这是一个坚实的设计而其refutal：Rich域名是实心的，血虚域是一个反模式

You can find this article very interesting: The Anaemic Domain Model is no Anti-Pattern, it’s a SOLID design And its refutal: Rich Domain Is SOLID , Anaemic Domain Is An Anti Pattern