这个类设计太靠近db表结构了吗?

时间:2012-01-03 12:12:03

标签: c# .net oop design-patterns database-design

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

在我的C#模型中,我有3个类:

  • class Item
  • class Group
  • class GroupItem

类Group有一个GroupItem集合,每个GroupItem类包含一个Item,如果有的话,添加和删除日期。

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

您怎么看?

3 个答案:

答案 0 :(得分:3)

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

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

我个人认为,它代表干净的映射并保留原样。在几个月之后,你将永远不会记住绑定的哪个fild,并且在code modeldb model之间已经相对连贯的映射将有助于所有的东西更容易理解, imo

答案 1 :(得分:1)

似乎GroupItemGroupItem之间是 qualified association

你必须问自己的问题是你是否真的需要一个合格的协会。鉴于你的entites非常通用的名字,我不知道。有三种情况需要考虑:

  • 如果项目仅由一个组持有,则您不需要合格的关联:关联中的信息(即日期)可以在项目中移动。这是一个简单的一对多关联。 Group有一个Item列表,您不需要额外的表格(Item的表格中有外键)。

  • 如果一个项目可以分成几组 - 我猜是这样 - 那么你可以选择:

    • 多对多关联。每个实体(ItemGroup)都有一个其他类型的实体列表。
    • 合格的关联。合格的关联通常以HashMapDateItem)或您所做的GroupItem的特殊集合来表示。

在后两种变体中,您需要一个额外的表来模拟数据库级别GroupItem之间的关联。

答案 2 :(得分:0)

每个类都有一个单独的表是很好的概念隔离。使用这种方法,你可以使用一些 ORM 工具来帮助实现良好的架构。

还有一些成熟的orm工具,如 NHibernate ,将提供不同类的类映射,如继承,组合,1-1关系,1多关系等。所以更好地使用ORM工具良好的域驱动开发