使用实体框架时是否应该使用部分类作为业务层？

发布于 2024-09-03 16:48:58 字数 174 浏览 14 评论 0原文

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

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

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

空气里的味道 2024-09-10 16:48:58

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

出于以下几个原因：

创建的实体模型包括一个深层关系对象模型，根据您的架构，该模型将暴露给 UI 层（例如 MVP 的呈现器或 MVVM 中的 ViewModel）。
业务逻辑层通常公开您可以对其进行编码的操作。如果您在 BLL 上看到一个保存方法，并查看执行保存所需的参数，并看到一个模型需要构建其他实体（由于实体模型的关系性质）只是为了执行保存，那么它并没有保留操作简单。
如果您有大量网络服务，则需要发送额外的数据，但不会带来明显的收益。
您可以为操作参数创建更多不可变的 DTO，而不是遇到副作用，因为同一实例在应用程序的其他部分被修改。
如果您进行 TDD 并遵循 YAGNI，那么您将倾向于拥有专门为您正在编写的操作设计的结构，这将更容易构建测试（不需要创建与测试无关的其他对象，因为它们都在模型上）。在这种情况下，您可能...
```
公共类订单
{ ...
    公共 Guid CustomerID { 获取；放; }
... }
```

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

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

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

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

I had a look at using partial classes and found that exposing the database model up towards the UI layer would be restrictive.

For a few reasons:

The entity model created includes a deep relational object model which, depending on your schema, would get exposed to the UI layer (say the presenter of MVP or the ViewModel in MVVM).
The Business logic layer typically exposes operations that you can code against. If you see a save method on the BLL and look at the parameters needed to do the save and see a model that require the construction of other entities (cause of the relational nature the entity model) just to do the save, it is not keeping the operation simple.
If you have a bunch of web services then the extra data will need to be sent across for no apparent gain.
You can create more immutable DTO's for your operations parameters rather than encountering side effects cause the same instance was modified in some other part of the application.
If you do TDD and follow YAGNI then you will tend to have a structure specifically designed for the operation you are writing, which would be easier to construct tests against (not requiring to create other objects not realated to the test just because they are on the model). In this case you might have...
```
public class Order
{ ...
    public Guid CustomerID { get; set; }
... }
```

Instead of using the Entity model generated by the EF which have references exposed...

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

This way the id of the customer is only needed for an operation that takes an order. Why would you need to construct a Customer (and potentially other objects as well) for an operation that is concerned with taking orders?

If you are worried about the duplication and mapping, then have a look at Automapper

回复收藏 0 原文

等数载，海棠开 2024-09-10 16:48:58

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

您失去了数据层和业务层之间的明确区别
这使得业务层更难以测试

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

回复收藏 0 原文

假面具 2024-09-10 16:48:58

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

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

回复收藏 0 原文

未蓝澄海的烟 2024-09-10 16:48:58

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

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

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

这能回答你的问题吗？

回复收藏 0 原文