Question

在3层项目中使用entity framework (EF)作为ORM工具，我发现实体框架生成的代码为DAL +一点BLL。由于DAL和BLL在此方案中是不同的层，并且不同的编码器将在每个层上工作，因此需要将每个层分隔为不同的项目。

问题是我不想更改EF生成的代码，仍然需要BLL的额外项目（我知道EF部分类和On...Changing() methods但这不是'理解我对概念的良好分离，也不能在不同的项目中实现部分类。）

我希望EF为每个实体生成一个接口，然后将其作为生成的代码实现。这样，我可以通过BLL类实现这些接口。然后对EF设计器中的实体进行更改将导致自动更改接口，我的BLL将停止工作（不再编译，因为接口已更改）。遗憾的是EF不提供这些接口并且从生成的代码中提取它们很难维护，因为对模型的任何新更改都需要再次手动提取它们。

然后我想到用我们自己的BLL类包装实体框架生成的类（从BLL类派生EF类）并在那里添加额外的BLL逻辑（验证，业务规则......）并隐藏具有BLL等价物的基础方法和属性。

// example of a new property which facilitates using an EF object

class EFaccount // EF generated class
{
   DateTime CreationDate { get; set; }
   DateTime ExpiranDate { get; set; }
}

class BLLaccount : EFaccount // BLL class
{
   new DateTime CreationDate { get; set; }
   new DateTime ExpiranDate { get; set; }
   // Total age in days as a new property. Storing this, in dbase cause unnecessary redundancy
   int Days { get { return (ExpirationDate - CreationDate).TotalDays; } }
}

由于BLL类是从它们的等效EF类派生的，所以我需要从一个不允许的基类进行转换。

在我的情况下，如果我从EF转换为BLL，则意味着对象来自dbase，并且可以从基类轻松计算额外属性，但编译器不允许从基类进行转换。如果我从BLL转换为EF，则意味着对象将被存储在dbase中，因此可以抛弃额外的属性，但编译器不允许转换为基础。

你有什么建议？

Answer 1

建议是：

使用实体框架4
使用实体对象或最好使用POCO
使用实体对象或POCO T4模板
修改T4模板以为您添加其他功能 - 应该可以基于实体属性生成和实现界面。

你不想要额外编码的论据是荒谬的。您已经证明，使用生成的代码需要大量额外的编码，并且您还有许多其他的复杂功能。生成并不意味着好。如果您无法修改生成代码，那么使用生成的代码并不容易（只有在编写自己的自定义工具进行代码生成时才有可能）。所以这里有T4模板的明显优势。

用户定义到基类和实体框架的转换

1 个答案: