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

我们正在使用ORM /领域建模工具，该工具将允许我们跨MSSQL数据库以“数据库优先”方法生成的多个项目/程序集中生成多个相关领域模型。我们需要一些帮助来确定哪些工具可以满足我们的需求。领域建模工具建议 - 跨项目关系和继承

的要求是：

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

，以支持（或有变通方法来支持）任何ORM工具的任何反馈这些标准将不胜感激！

注：工具我们已经看过了（但这并不排除他们完全）：

LightSpeed（可爱，但不轻易支持跨项目继承）。
LLBLGen（复杂且包含所有内容，但使用AsSeparateProjects模式进行分组时似乎不支持跨模型关系，更不用说继承了）。
实体框架（我刚刚失去了...当设计师的故事splitting the domain across multiple models不是很好）。

2011-03-08 Reddog

当选择AsSeparateProjects时，LLBLGen Pro不支持通过组进行连接，因为该模型会导致多个vs.net项目。如果我们允许跨越组边界的连接（如您所请求的那样），那么vs.net项目最终会相互引用，这是不可能的，因为这会导致循环引用。 – 2012-05-18 07:58:34

这绝对需要小概念验证项目，因为您的要求不是在EF有关论文中通常描述的内容。

对于1.和2.通过这些文章（part 1,part 2），并尝试做出简单的解决方案，这将证明你能够在多个EDMX中使用关系和继承。

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

来源

2011-03-08 07:48:16

对于这一个记录：经过大量的概念验证工作，我们使用实体框架。我们正在使用类似于EdmGen2的自建命令行工具来完成上面链接的第2部分中提到的所有CSDL内容，同时仍然使用设计器。这一切都很好，现在轻松地挂在一起！我希望很快就能发布它 - 所以请留意这个空间。 – Reddog 2011-04-07 20:45:23

虽然它听起来像是你要求的相反，但我可能会看EF Code First。因为它都建立在POCO，DbSets和DbContext类之上，所以你可以很容易地获得继承。

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

在WinForms前面，有example code here关于如何使集合可观察。你需要自己照顾INotifyPropertyChanged，但这很容易。

对于您来说EF Code First的缺点是没有办法只生成所有的类。话虽如此，但他们足够简单，可以在编写应用程序的其余部分时按照需要编写它们。任何形式的通用自动化工具都无法确定哪些模型和属性与客户特定的属性相同。

来源

2011-03-08 19:58:47

我对EF Code First的直接反应是POCO非常简单 - 我认为这一点真的很重要......实际上，我们希望支持POCO之上的众多方面，而无需手工编写所有内容。例如，INotifyPropertyChanged支持和部分“On ... Changed”方法。实际情况是，关键领域行为的大部分都是在On ..Changed中执行的，属性改变了相关实体的反应，以及属性验证。也就是说，我们通常添加到生成模型顶部的部分类的所有好东西（INotifyPropertyChanged实现除外）。 – Reddog 2011-03-08 21:52:14

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

回答

相关问题