.net 当需要依赖项时，如何/在何处将业务逻辑放入EF实体？

我正在尝试为我的应用程序编写一些业务逻辑。我的应用程序的核心是由数据库优先模型生成的EF实体。我已将生成的类（.tt文件）与.edmx部分分开

我想找到放置业务逻辑的最佳位置，但问题是，业务逻辑需要一些复杂的依赖关系，例如，需要日志记录、调用某些Web服务或对DB进行纯SQL调用正因为如此，我不能只在函数中使用new（）并创建硬依赖项，但我希望遵循DI原则，以某种方式从它们中抽象出来

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

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

但在阅读了一些文章后，我现在认为将依赖项注入EF类不是一个好主意：

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

1） 将业务逻辑（需要依赖项）放在服务层内。这可能会导致领域模型的贫乏，但也许服务层是这种需要依赖关系的逻辑的正确位置

2） 创建一些king或Wrapper/Factory类，每次查询返回实体时都需要调用这些类，这样我就可以用业务逻辑包装实体

3） 将该逻辑放在其他一些类中，这些类将实体作为函数参数

---

这方面有哪些好的、常见的做法？

问题是您混合了两种相反的设计：DDD和贫血模型

• DDD：就业务逻辑而言，不可能存在依赖关系，因为对象本身就是必须实现它的对象
• 贫血模型：这是治疗EF的常用方法。这些对象是POCOS：Fowler说“袋子的属性设定者和吸气剂”，并认为它是一种反模式。所有逻辑都在接收实体的服务中实现，并根据业务规则对其进行更改

如果使用DDD

应用程序中的类必须是域对象（实体和值对象）。您必须实现它们，而不考虑它们将如何存储在数据库中（或您使用的任何后端）。完成域对象设计后，将实现满足域对象持久性需求的EF模型。因此，在许多情况下，域对象（实体和值对象）与EF实体之间不存在直接映射

也就是说，在这个实现中，您的域对象必须在某个点存储数据。您必须实现一个EF模型，该模型支持存储这些数据

至于依赖项，在这种情况下，它们将位于域对象中，而不是EF实体中。然后您可以使用通常的模式（工厂、DI）来创建域模型。其中一个依赖项可能是使用EF实现的存储库

如果您使用贫血模型

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

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

大错误

贫血模型通常是以数据为中心设计的结果。用福勒的话说：我不知道为什么这种反模式如此普遍。我怀疑这是由于许多人没有真正使用正确的域模型，特别是如果他们来自数据背景。所以，如果您从这样做开始：在我的应用程序的核心是从Database First模型生成的EF实体。您将很难实现纯DDD（）

回答你的意见：

1） 这是一个贫血模型

2） 您希望存储的数据直接映射到域对象。您收到一个实体并希望向其添加功能。不！您的域对象必须使用EF来请求持久化数据，而不是相反

3） 这又是一次

---

你会发现这篇文章非常有趣：它的补充：

很抱歉，但打破EF依赖不是我要说的。我想抽象出EF POCOs/域类在执行业务逻辑时所具有的依赖性。你的问题很混乱，因为你混淆了概念。我已经更新了我的答案。+1有几处提到：值对象也是域对象，贫乏的域也就是过程方法，当你只是移动数据时有效，但当你的应用程序充满经常变化的上下文业务规则时失败（这并不是说它不起作用，但在不破坏东西的情况下快速实施更改是一种痛苦）。贫血领域存在可维护性问题。关于那篇文章，这里是@andree，当你开始使用数据库时，它是一个数据库驱动的设计，而不是域驱动的。也许会帮助你理解为什么以db开头是错误的。@MikeSW我已经为你的有趣文章添加了参考资料：非常有趣的博客。谢谢你的评论！