用户定义的与基类和实体框架之间的转换答案

【问题标题】：User-defined conversions to or from a base class and entity-framework用户定义的与基类和实体框架之间的转换
【发布时间】：2011-06-29 14:30:00
【问题描述】：

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

问题是我不想更改 EF 生成的代码，并且仍然需要一个额外的 BLL 项目（我知道 EF 部分类和 On...Changing() methods 但这并没有什么意义对我而言，概念分离以及部分类无法在不同的项目中实现）。

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

然后我想到用我们自己的 BLL 类（从 EF 类派生 BLL 类）包装实体框架生成的类，并在那里添加额外的 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 中，因此可能会丢弃额外的属性，但编译器不允许转换为 base。

你有什么建议？

【问题讨论】：

为什么不直接跳过代码生成并使用 POCO 呢？
当我想尽量减少额外的编码时，这是一项额外的工作

标签： entity-framework casting

【解决方案1】：

建议是：

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

你不想要额外编码的论点是荒谬的。您已经证明，使用生成的代码需要大量额外的编码，并且会带来很多额外的复杂性。生成并不意味着好。如果您无法修改生成的代码，那么使用生成的代码并不容易（这只有在您编写自己的自定义代码生成工具时才有可能）。这就是 T4 模板的明显优势。

【讨论】：