在使用实体框架时，我应该使用分部类作为业务层吗？

Question

我正在做一个使用实体框架的项目。可以使用EF生成的类的部分类作为业务层吗？我开始认为这就是EF的用法。

我曾尝试使用DTO模式，并很快意识到我只是创建了一堆映射类，这会重复我的工作，也会导致更多的维护工作和额外的层。

我想使用self-tracking-entities并将EF实体传递给所有层。请分享你的想法和想法。谢谢

Answer 1

我看过使用分部类，发现将数据库模型向上公开到UI层是有限制的。

出于几个原因：

1. 创建的实体模型包括一个深关系对象模型，根据您的模式，该对象模型将公开给UI层(比如MVP的提示者或MVVM中的ViewModel )。
2. 业务逻辑层通常公开您可以针对其进行编码的操作。如果您在BLL上看到一个save方法，并查看执行保存所需的参数，并且看到一个仅为了执行保存而需要构造其他实体(由于实体模型的关系性质)的模型，那么它并没有保持操作的简单性。
3. 你可以为你的操作参数创建更多的不可变的

，而不是遇到副作用。

1. 你可以为你的操作参数创建更多的不可变的DTO，而不是遇到副作用，因为相同的实例在你进行测试的其他部分被修改了，然后你将倾向于有一个专门为你正在编写的操作设计的结构，这将更容易构建测试(不需要创建其他与测试无关的对象，因为它们在模型上)。在这种情况下你可能有..。

公共类顺序{ ...公共Guid CustomerID { get；set；} ... }

而不是使用由EF生成的具有公开引用的实体模型……

public class Order
{ ...
    public Customer Customer { get; set; }
... }

这样，只有接受订单的操作才需要客户的id。为什么需要为与接受订单相关的操作构造一个Customer (以及可能的其他对象)？

如果您担心复制和映射，那么可以看看Automapper

Answer 2

我不会这样做，原因如下：

1. 您失去了数据层和业务层之间的清晰区别
2. 使业务层更难测试

但是，如果您有一些特定于数据模型的代码，请放置部分类，以避免在重新生成模型时丢失它。

Answer 3

我是不会做那种事儿的。尽量保持各层的独立性。因此，数据库模式中的微小更改不会影响所有层。

实体可以用于数据层，但不应该用于数据层。如果有的话，提供要使用的接口，并让你的实体实现它们(在部分文件上)。BL不应该知道实体，而应该知道接口。