我从事C#和Java编程已有一年多了,并且对面向对象编程有相当的了解,但是我的新项目需要数据库驱动的模型。我正在使用C#和Linq,这似乎是一个非常强大的工具,但是在围绕面向对象的方法设计数据库时遇到了麻烦。
我的两个主要问题是:
如何处理数据库中的继承? 假设我正在构建人员名册应用程序,并且有一个抽象类Event。从事件中,我派生出抽象类ShiftEvent和StaffEvent。然后,我有具体的类Shift(从ShiftEvent派生)和StaffTimeOff(从StaffEvent派生)。还有其他派生类,但出于争论的目的,这些就足够了。
我应该为ShiftEvents和StaffEvents提供单独的表格吗?也许每个具体的班级我应该有单独的表格?与数据库交互时,这两种方法似乎都会给我带来问题。另一种方法可能是拥有一个事件表,并且该表将为我的任何具体类中的每种数据类型提供可为空的列。所有这些方法都感觉它们可能会阻碍将来的可扩展性。我没有考虑过第三种方法。
我的第二个问题:
如何以面向对象的方式处理集合和一对多关系?
假设我有一个Products类和一个Categories类。每个类别的实例将包含一个或多个产品,但是产品本身不应该具有类别的知识。如果要在数据库中实现此功能,则每个产品都需要一个类别ID,该ID映射到类别表。但这引入了比从OO角度我更喜欢的耦合。产品甚至不应该知道类别的存在,更不用说包含类别ID的数据字段了!有没有更好的办法?
Linq to SQL使用每个类的表解决方案:
http://blogs.microsoft.co.il/blogs/bursteg/archive/2007/10/01/linq-to-sql- inheritance.aspx
其他解决方案(例如我最喜欢的LLBLGen)允许使用其他模型。就个人而言,我喜欢带有区分符列的单表解决方案,但这可能是因为我们经常跨继承层次结构进行查询,因此将其视为常规查询,而查询特定类型仅需要“ where”更改。
总而言之,我个人认为将OO映射到表中就是把购物车摆在了前面。一直有人声称OO和关系之间的阻抗不匹配已经得到解决…并且已经有很多OO特定的数据库。他们中没有一个人拥有这种关系的强大简单性。
相反,我倾向于在设计数据库时考虑到应用程序,将这些表映射到实体并从那里构建。有人认为这是设计过程中OO的损失,但是在我看来,数据层不应该在您的应用程序中讲得足够高,以至于影响高阶系统的设计,只是因为您使用了关系模型 进行存储 。