我已经用C#和Java编程了一年多一点,对面向对象编程有很好的把握,但是我的新方项目需要一个数据库驱动的模型.我正在使用C#和Linq,这似乎是一个非常强大的工具,但我在设计面向对象方法的数据库方面遇到了麻烦.
我的两个主要问题是:
我如何处理数据库中的继承？ 假设我正在建立一个员工排班应用程序,我有一个抽象类,事件.从Event I派生出抽象类ShiftEvent和StaffEvent.然后我有具体的类Shift(派生自ShiftEvent)和StaffTimeOff(派生自StaffEvent).还有其他派生类,但为了论证,这些就足够了.
我是否应该为ShiftEvents和StaffEvents提供单独的表？也许我应该为每个具体类别都有单独的表格？这两种方法似乎都会在与数据库交互时给我带来问题.另一种方法可能是拥有一个Event表,并且该表对于我的任何具体类中的每种类型的数据都有可为空的列.所有这些方法都觉得它们可能阻碍可扩展性.很可能还有第三种方法,我没有考虑过.
我的第二个问题:
如何以面向对象的方式处理集合和一对多关系？
假设我有一个Products类和一个Categories类.每个类别实例都包含一个或多个产品,但产品本身应该不了解类别.如果我想在数据库中实现它,那么每个产品都需要一个映射到类别表的类别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的损失,但在我看来,数据层不应该高度说话,而是要影响高阶系统的设计,因为你使用关系模型进行存储.
我遇到了相反的问题:经过多年的数据库设计,如何让我的头脑清醒.谈到这一点,十年前,我遇到了在经过多年"结构化"平面文件编程后逐渐掌控SQL的问题.类和数据实体分解之间有足够的相似之处,误导你认为它们是等价的.他们不是.
我倾向于同意这样的观点:一旦你致力于存储关系数据库,那么你应该设计一个规范化的模型,并在不可避免的情况下妥协你的对象模型.这是因为您使用DBMS比使用自己的代码更受限制 - 构建受损数据模型更有可能让您感到痛苦.
也就是说,在给出的示例中,您有以下选择:如果ShiftEvent和StaffEvent在属性方面大致相似并且通常作为事件一起处理,那么我倾向于使用类型列实现单个Events表.单表视图可以是分离子类的有效方法,并且在大多数数据库平台上都是可更新的.如果类在属性方面更加不同,那么每个类的表可能更合适.我不认为我喜欢三桌的想法:"有一个或没有"关系在关系设计中很少需要.无论如何,您始终可以创建一个事件视图作为两个表的并集.
对于产品和类别,如果一个类别可以有许多产品,反之则不然,那么表示这种情况的正常关系方式是产品包含类别ID.是的,它是耦合,但它只是数据耦合,而且它不是致命的罪.该列可能应该被编入索引,因此检索类别的所有产品是有效的.如果你对这个概念感到非常恐惧,那么假装它是一个多对多的关系,并使用一个单独的ProductCategorisation表.这并不是什么大不了的事,虽然这意味着潜在的关系并不存在,并且可能会误导未来的应用程序.
在我看来,这些范例(关系模型和OOP)适用于不同的域,使得尝试在它们之间创建映射变得困难(并且毫无意义).
关系模型是关于表示事实(例如"A是一个人"),即具有"独特"属性的无形事物.它没有意义谈论几个同一事实"实例" -仅存在的事实.
面向对象编程是一种编程范例,详细描述了构建计算机程序以满足某些标准(重用,多态,信息隐藏......)的方法.一个对象通常是一些有形的东西的隐喻 - 汽车,引擎,经理或人等.有形的东西不是事实 - 可能有两个不同的对象具有相同的状态而没有它们是同一个对象(因此它们之间的区别例如,在Java中等于和==).
Spring和类似工具以编程方式提供对关系数据的访问,因此事实可以由程序中的对象表示.这并不意味着OOP和关系模型是相同的,或者应该与彼此混淆.使用Realational Model设计数据库(事实集合)和OOP来设计计算机程序.
TL; DR版本(物体 - 关系阻抗不匹配蒸馏):
事实=冰箱上的食谱.物体=冰箱的内容.
京公网安备 11010802040832号 | 京ICP备19059560号-6 