Question

我正在使用实体框架开展项目。是否可以使用EF生成的类的部分类作为业务层。我开始认为这就是EF的用途。

我试图使用DTO模式，很快意识到我只是创建了一堆映射类，这些类重复了我的工作量，也是更多维护工作和附加层的原因。

我想使用自我跟踪实体并将EF实体传递给所有图层。请分享您的想法和想法。感谢

Answer 1

我看过使用部分类，发现向UI层公开数据库模型会受到限制。

有几个原因：

创建的实体模型包括一个深层关系对象模型，根据您的模式，该模型将暴露给UI层（比如MVP的演示者或MVVM中的ViewModel）。
业务逻辑层通常会公开您可以编码的操作。如果你在BLL上看到一个save方法并查看执行保存所需的参数，并查看需要构建其他实体的模型（实体模型的关系性质的原因）只是为了进行保存，它不会保留操作简单。
如果你有一堆网络服务，那么需要发送额外的数据才能获得明显的收益。
您可以为操作参数创建更多不可变的DTO，而不是遇到副作用，因为在应用程序的其他部分修改了相同的实例。
如果您使用TDD并遵循YAGNI，那么您将倾向于拥有专门为您正在编写的操作设计的结构，这将更容易构建测试（不需要创建其他不依赖于测试的对象）只是因为他们在模特身上）。在这种情况下，您可能有......
```
public class Order
{ ...
    public Guid CustomerID { get; set; }
... }
```

而不是使用EF生成的实体模型，其中有参考公开...

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

这样，只有接受订单的操作才需要客户的ID。为什么需要为涉及接受订单的操作构建Customer（以及可能还有其他对象）？

如果您担心重复和映射，请查看Automapper

Answer 2

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

您忽略了数据层与业务层之间的明显区别
这使得业务层更难以测试

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

Answer 3

我不会这样做。尽量保持图层独立。因此，数据库架构中的微小更改不会影响所有层。

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

Answer 4

我认为部分课程是个好主意。如果重新生成模型，那么您将不会丢失部分类中的业务逻辑。

作为替代方案，您也可以只查看EF4代码，这样就不需要从数据库生成模型了。

Answer 5

我会使用部分类。 DDD-ish代码中没有数据层这样的东西。有一个数据层，它驻留在SQL Server上。应用程序代码应该只包含业务层和一些映射，这些映射允许在所提到的数据层中持久保存业务对象。

实体框架是您的数据访问代码，因此您不应构建自己的数据访问代码。在大多数情况下，数据库模式将被修改，因为模型已更改，而不是相反。

话虽这么说，但我不鼓励你在所有层面分享你的实体。我重视UI和域层的分离。我会使用DTO将数据传入和传出域。如果我有必要的自由，我甚至会使用CQRS模式来摆脱映射实体到DTO - 我只是创建第二个EF数据访问项目，仅用于读取UI的数据。它将建立在同一个数据库之上。您通过读取（贫血 - 没有业务逻辑）模型读取数据，但是您可以通过发出针对使用EF和部分方法实现的实际模型执行的命令来修改数据。

这会回答你的问题吗？

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

5 个答案: