在使用实体框架时，应该使用部分类作为业务层吗？ [英] Should i use partial classes as business layer when using entity framework?

问题描述

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

我试图使用DTO模式，很快意识到我只是创建了一堆映射课程正在复制我的努力，也是更多维护工作和附加层的原因。

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

解决方案

我看过使用部分类，发现将数据库模型暴露给UI层将是有限制的。

由于以下原因：

1. 创建的实体模型包含一个深层关系根据您的架构，对象模型将暴露于UI层（例如，MVP的演示者或MVVM中的ViewModel）。


2. 业务逻辑层通常会暴露您可以编码的操作。如果您看到BLL上的保存方法，并查看执行保存所需的参数，并查看需要构建其他实体（实体模型的关系属性的原因）的模型才能执行保存，则不会保留操作简单。


3. 如果您有一堆网络服务，那么额外的数据将需要发送，无法明显收获。


4. 您可以创建更多不变的DTO对于您的操作参数而不是遇到副作用，导致在应用程序的其他部分修改了相同的实例。



5. 如果您做TDD并遵循YAGNI，那么您将趋向于具有专门为您正在编写的操作设计的结构，这将更容易构建测试（不需要创建其他对象，而不是因为它们在模型上而不能实现）。在这种情况下你可能有...

     public class Order 
    {... 
    public Guid CustomerID {get;组; 
    ...} 
     

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

  public class Order 
 {。 .. 
 public客户{get;组; } 
 ...} 
  

这样，只需要一个客户的id执行命令的操作。为什么您需要为涉及订单的操作构建一个客户（以及潜在的其他对象）？

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

I am working on a project using entity framework. Is it okay to use partial classes of the EF generated classes as the business layer. I am begining to think that this is how EF is intended to be used.

I have attempted to use a DTO pattern and soon realized that i am just creating a bunch of mapping classes that is duplicating my effort and also a cause for more maintenance work and an additional layer.

I want to use self-tracking-entities and pass the EF entities to all the layers. Please share your thoughts and ideas. Thanks

解决方案

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:

1. 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).
2. 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.
3. If you have a bunch of web services then the extra data will need to be sent across for no apparent gain.
4. 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.

5. 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

这篇关于在使用实体框架时，应该使用部分类作为业务层吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！