这个类设计太接近db表结构了？答案

【问题标题】：This class design is too close to the db table structure?这个类设计太接近db表结构了？
【发布时间】：2012-02-01 11:35:48
【问题描述】：

我有一个包含以下表格 Items、Groups 和 GroupItems 的数据库。 Items 表包含每个项目的设置，groups 表包含一些组的定义，GroupsItems 表包含每个项目到每个组的链接以及项目添加到组的日期和项目的日期删除（如果有的话）。

在我的 C# 模型中，我有 3 个类：

Group 类有一个 GroupItem 集合，每个 GroupItem 类包含一个 Item 以及添加和删除的日期（如果有）。

我不确定这是否是一个好的设计，或者我是否正在将数据库结构移动到我的应用程序模型中。如果我将这两个日期直接移动到类 Item 中，并且将类的数量减少一，从而降低软件复杂性，会更好吗？

你怎么看？

【问题讨论】：

【解决方案1】：

如果可以，通过删除 GroupItem 类并将其“拆分”到架构中的 Item 中，这是一个不错的选择。您唯一需要考虑的是，此时您必须重新映射数据库映射。

这里的选择是在您的应用的干净架构和您的应用和数据库之间的干净映射之间。

就我个人而言，我支持clean mapping，并保持原样。几个月后，您将永远不会记得绑定了哪个字段，并且在您的code model 和db model 之间已经相对一致地映射将有助于所有东西更容易理解，imo。

【讨论】：

【解决方案2】：

似乎GroupItem 是Group 和Item 之间的qualified association。

您必须问自己的问题是您是否真的需要一个合格的协会。鉴于您的实体的通用名称，我不知道。需要考虑三种情况：

如果一个项目只被一个组持有，你不需要一个合格的关联：关联中的信息（即日期）可以在项目中移动。这是一个简单的一对多关联。 Group 有一个 Item 列表，您不需要额外的表（Item 的表有一个外键到组）。
如果一个项目可以分成几组——我猜是这样——那么你可以选择：
- 多对多关联。每个实体（Item 或 Group）都有一个其他类型的实体列表。
- 一个合格的协会。合格的关联通常用HashMap（Date、Item）表示，或者像您所做的那样，用GroupItem 的特殊集合表示。

在后两种变体中，您需要一个额外的表来在数据库级别对Group 和Item 之间的关联进行建模。

【讨论】：

【解决方案3】：

每个类都有一个单独的表是很好的概念分离。通过这种方法，您可以使用一些 ORM 工具来帮助构建良好的架构。

还有一些成熟的orm工具如NHibernate会提供不同类型的类映射，如继承、组合、1-1关系、1-多关系等。所以最好使用ORM工具一个好的领域驱动开发

【讨论】：