Question

我正在使用MVVM模式构建一个小型计时应用程序，使用实体框架进行持久化。在这个阶段，我的逻辑很薄，因为我只需要对相关数据执行一些计算和聚合。目前，我已经通过在实体类的部分类中编写它们来实现这些。

例如：

// entity framework generated
partial class Lap {
  int Id { /* boilerplate */ }
  DateTime StartTime { /* etc */ }
  DateTime EndTime { /* etc */ }
}

// in my partial class (written by me)
partial class Lap {
  TimeSpan Duration {
    get { return EndTime - StartTime; }
  }
}

将额外的逻辑直接放到实体生成的类上是不好的做法？我应该为这个逻辑创建另一个域层吗？

Answer 1

你正在做的是设计部分类的事情;将相关逻辑添加到代码生成的类中，而不会使继承树陷入困境。坚持下去。

增加：

从所有部落知识字体的页面Wikipedia（强调添加）：

部分课程的目的是   允许类的定义跨越   跨多个文件。它是   特别适用于：


非常大的类（使用编辑器导航很麻烦）   通过单个文件）

以与面向方面的编程类似的方式分离关注点   但不使用任何额外的工具。一个   示例如下所示。

允许多个开发人员同时处理单个类   时间不需要以后   合并源代码管理中的文件。

允许类接口和类之间的分离   与实施有关的定义   （公众的不同定义   和私人部分）

简化代码生成器的编写，例如可视化设计器。   这可能是最有用的   理由。发展是一项挑战   可以管理的代码生成器   放入时生成的代码   人工编写的代码：

需要大量解析不必要的代码，只是为了找到一个   插入生成的代码的位置。   改变代码也是一个问题。   写得不好的发电机持有   潜在的破坏整个风险的风险   文件。




使用部分类，代码   生成器处理单独的文件，   从而减轻了所有人的负担   上面提到的问题。

Answer 2

我不得不承认对POCO这样做，并且发现它非常有成效。其他常见用途

Fullname = FirstName +“”+姓氏
CostIncl = Excl + Tax
有时也可以聚合子实体中的总计（例如InvoiceTotal =所有LineItem.Totals的总和）

等

有一些警告

如果您直接通过网络发送这些实体（例如WCF或ASMX），请确保它们未标记为Serializable / DataMember，因为它们将在没有setter的情况下无法序列化
如果你不是（例如将它们映射到电线上或用于MVVM目的），你将需要重复工作
编辑：根据Stephen的评论，在LINQ查询中使用派生属性（命中SQL）将失败（因为它无法映射到SQL）。

Answer 3

使用实体框架时，使用实体的部分类并不错。但是，您只需确保不将业务逻辑与部分类成员中的数据访问逻辑混合使用。否则，如果没有连接到数据库，就很难编写单元测试代码。

WPF Application Framework (WAF) 的 BookLibrary 示例显示了当域图层使用EF实体时WPF MVVM应用程序的外观。

使用分部类向EF实体添加功能是不好的做法吗？

3 个答案: