领域建模工具建议 - 跨项目关系和继承答案

【问题标题】：Domain Modelling tool advice - cross project relationships and inheritance领域建模工具建议 - 跨项目关系和继承
【发布时间】：2011-07-10 19:23:05
【问题描述】：

我们正在寻求一种 ORM/域建模工具，它允许我们跨多个项目/程序集生成多个相关的域模型，这些项目/程序集以“数据库优先”的方法从我们的 MSSQL 数据库生成。我们需要一些帮助来确定哪些工具可以满足我们的需求。

要求是：

跨项目关系
- 我们的域被分成许多模块，对于每个客户（我们向其提供源代码）我们并不使用所有模块，因此我们希望“拔掉”他们不需要查看或查看的所有逻辑访问。
- 例如，我们希望将共享数据（主要是通用查找信息）存储在它自己的通用程序集中。
- 我们不需要模型之间的双向关系（因为这会导致循环引用）。只会生成关系的子端。
跨项目继承
- 与上述类似，我们希望能够将通用功能抽象为一个域模型中的基类并继承它们。
- 注意：域之间的继承链接将受到限制，每个子域只有一个或两个。
- 注意：这无关紧要，但我们使用“每个类型的表”或“Class Table Inheritance”在我们的关系 (DB) 架构中对继承进行建模
生成的类是：
1. 标有 DataContract/DataMember 属性
2. 通知属性更改（通过 INotifyPropertyChanged 实现）
3. 具有部分 On*PropertyName*Changed() 方法（例如，根据 Linq to SQL 和实体框架生成的对象）
4. （理想，但不是必需的）相关集合类型应实现 INotifyCollectionChanged。

对于任何支持（或具有支持）这些标准的 ORM 工具的任何反馈，我们将不胜感激！

注意：我们研究过的工具（但这并不能完全排除它们）：

【问题讨论】：

LLBLGen Pro 不支持在选择 AsSeparateProjects 时跨组连接，因为该模型将导致多个 vs.net 项目。如果我们允许跨组边界的连接（如您所要求的），vs.net 项目最终会相互引用，这是不可能的，因为它会导致循环引用。

【解决方案1】：

这肯定需要小型概念验证项目，因为您的要求不是关于 EF 的论文中通常描述的内容。

对于 1. 和 2. 阅读这些文章 (part 1, part 2) 并尝试制作简单的解决方案，以证明您能够在多个 EDMX 之间使用关系和继承。

用于从 EDMX 生成类的自定义 T4 模板将满足最后一点 - 从 POCO 模板开始并更改其生成功能。

【讨论】：

为了记录这一点：经过大量的概念验证工作，我们正在使用实体框架。正在使用类似于 EdmGen2 的自构建自定义命令行工具来执行上面链接的第 2 部分中提到的所有 CSDL 内容，同时仍使用设计器。现在这一切都很好而且很容易地挂在一起！我希望尽快写博客 - 所以请注意这个空间。

【解决方案2】：

虽然听起来可能与您的要求相反，但我可能会查看EF Code First。因为它全部建立在 POCO、DbSet 和 DbContext 类之上，所以您将能够非常轻松地使继承工作。

在公共程序集中拥有您的共享模型和抽象 DbContext。在客户特定的程序集中拥有特定的模型和最终的 DbContext。

在 WinForms 前端，example code here 说明了如何使集合可观察。您需要自己处理 INotifyPropertyChanged，但这很容易。

EF Code First 的缺点是无法生成所有类。话虽如此，它们写起来很简单，我可能会在您编写应用程序的其余部分时根据需要编写它们。任何形式的通用自动化工具都难以确定哪些模型和属性属于共同的，哪些属于客户特定的。

【讨论】：

我对 EF Code First 的直接反应是 POCO 非常简单——我想这就是重点……我们真的希望在 POCO 之上支持许多方面，而无需手写商场。例如，INotifyPropertyChanged 支持和部分“On...Changed”方法。现实情况是，大部分关键领域行为都是在 On..Changed、相关实体的属性更改反应和属性验证中实现的。也就是说，我们通常在生成的模型之上添加到部分类的所有好东西（INotifyPropertyChanged 实现除外）。