问题描述
我从事C#和Java编程已有一年多了，并且对面向对象的编程有相当的了解，但是我的新项目需要数据库驱动的模型.我正在使用C#和Linq，这似乎是一个非常强大的工具，但是在围绕面向对象的方法设计数据库时遇到了麻烦.
I have been programming in C# and Java for a little over a year and have a decent grasp of object oriented programming, but my new side project requires a database-driven model. I'm using C# and Linq which seems to be a very powerful tool but I'm having trouble with designing a database around my object oriented approach.
我的两个主要问题是:
如何处理数据库中的继承?假设我正在构建人员名册应用程序，并且有一个抽象类Event.从事件中，我派生出抽象类ShiftEvent和StaffEvent.然后，我有具体的类Shift(从ShiftEvent派生)和StaffTimeOff(从StaffEvent派生).还有其他派生类，但出于争论的目的，这些就足够了.
How do I deal with inheritance in my database?Let's say I'm building a staff rostering application and I have an abstract class, Event. From Event I derive abstract classes ShiftEvent and StaffEvent. I then have concrete classes Shift (derived from ShiftEvent) and StaffTimeOff (derived from StaffEvent). There are other derived classes, but for the sake of argument these are enough.
我应该为ShiftEvents和StaffEvents提供单独的表格吗?也许每个具体的班级我应该有单独的表格?与数据库交互时，这两种方法似乎都会给我带来问题.另一种方法可能是拥有一个事件表，并且该表将为我的任何具体类中的每种数据类型提供可为空的列.所有这些方法都感觉它们可能会阻碍将来的可扩展性.我很可能没有考虑第三种方法.
Should I have a separate table for ShiftEvents and StaffEvents? Maybe I should have separate tables for each concrete class? Both of these approaches seem like they would give me problems when interacting with the database. Another approach could be to have one Event table, and this table would have nullable columns for every type of data in any of my concrete classes. All of these approaches feel like they could impede extensibility down the road. More than likely there is a third approach that I have not considered.
我的第二个问题:
我如何以面向对象的方式处理集合和一对多关系?
假设我有一个产品"类和一个类别"类.每个类别的实例将包含一个或多个产品，但是产品本身不应该具有类别的知识.如果要在数据库中实现此功能，则每个产品都需要一个类别ID，该ID映射到类别表.但这引入了比从OO角度我更喜欢的耦合.产品甚至不应该知道类别的存在，更不用说包含类别ID的数据字段了！有更好的方法吗?
Let's say I have a Products class and a Categories class. Each instance of Categories would contain one or more products, but the products themselves should have no knowledge of categories. If I want to implement this in a database, then each product would need a category ID which maps to the categories table. But this introduces more coupling than I would prefer from an OO point of view. The products shouldn't even know that the categories exist, much less have a data field containing a category ID! Is there a better way?
推荐答案
使用每类表的表实现SQL的Linq:
Linq to SQL using a table per class solution:
http: //blogs.microsoft.co.il/blogs/bursteg/archive/2007/10/01/linq-to-sql-inheritance.aspx
其他解决方案(例如我最喜欢的LLBLGen)允许其他模型.就个人而言，我喜欢带有区分符列的单表解决方案，但这可能是因为我们经常跨继承层次结构进行查询，因此将其视为常规查询，而查询特定类型仅需要"where"更改.
Other solutions (such as my favorite, LLBLGen) allow other models. Personally, I like the single table solution with a discriminator column, but that is probably because we often query across the inheritance hierarchy and thus see it as the normal query, whereas querying a specific type only requires a "where" change.
总而言之，我个人认为将OO映射到表中就是把购物车摆在了前面.一直有人声称OO和关系之间的阻抗不匹配已经得到解决...并且已经有很多OO特定的数据库.他们中没有一个人拥有这种强大的关系的简单性.
All said and done, I personally feel that mapping OO into tables is putting the cart before the horse. There have been continual claims that the impedance mismatch between OO and relations has been solved... and there have been plenty of OO specific databases. None of them have unseated the powerful simplicity of the relation.
相反，我倾向于在设计数据库时考虑到应用程序，将这些表映射到实体并从那里构建.有人认为这是设计过程中OO的损失，但是在我看来，数据层不应足够高地与您的应用程序对话以影响高阶系统的设计，因为您使用的是关系模型用于存储.
Instead, I tend to design the database with the application in mind, map those tables to entities and build from there. Some find this as a loss of OO in the design process, but in my mind the data layer shouldn't be talking high enough into your application to be affecting the design of the higher order systems, just because you used a relational model for storage.
这篇关于面向对象的程序员如何才能掌握数据库驱动的编程方法?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！