实体框架 4，继承与扩展？
每种方法的优点/缺点是什么？
我知道我在一本书或这个网站上读过为什么使用表继承对于 Entity Framework 4 来说很糟糕。
例如，为什么不创建一个具有entityId、datecreated、datemodified 的表，然后让所有其他类继承该表在实体框架中？然后我的所有其他实体的表不需要有这些列。然后我可以让一个人类继承该基类，然后让一个特定的人继承人。
我不确定这样做的优点，除了编写一个较小的 SQL 脚本来生成数据库之外...
我看到的缺点是，它使直接在 SQL 中查询/查看数据变得非常痛苦（所有相关信息都是打破了这么多桌子），我还问了我的朋友，他说：
“对我来说最重要的事情是，我不希望我的数据库依赖于我的应用程序当前的继承结构。如果出于某种原因，我想在继承方面改变我的应用程序的设计，这并不重要，因为我的数据不会依赖于我当前的系统设计，我认为数据存储只是根据正确的数据库设计进行标准化的，但继承是应用程序的编程选择。在设计应用程序时，更改应用程序代码比更改和迁移数据库数据要容易得多。 当大多数经验不足的开发人员处理问题时，他们会通过继承来处理它。我刚开始开发时也是这么做的。这在逻辑上是有道理的。然而，一旦开发了很长一段时间，您就会发现委派确实是最好的方式（在 soa 的情况下，服务调用服务），并且单一用途的服务比继承提供更多的重用。”
这对我来说也很有意义。
所以
1）一般来说，继承与扩展的优点/缺点是什么
2）在我上面的具体例子中，什么会更合适？
3）如果我的示例对于其中一个或两个都很糟糕，那么使用继承和使用扩展的好例子是什么？
我以前都用过，但由于我还没有经验丰富，我仍然不确定如何处理所有情况。
10 票、8 人收藏、过百浏览却没人扩展？ =（。
What are the advantages/disadvantages to each method?
I know I've read somewhere in either a book or on this site why using table inheritance is crappy for Entity Framework 4.
For instance, why not make one table which has an entityId, datecreated, datemodified and then have every other class inherit that in entity framework? Then my tables for all other entities don't need to have those columns. Then I can have a person class inherit that base class, and then a specific person inherit person.
I am not sure of the advantages of this though other than writing a smaller SQL script to generate the database...
Disadvantages I see are that it makes querying /viewing the data directly in SQL a big pain in the ass (all relevant information is broken across so many tables), and I also asked my friend who said:
"The biggest thing that sticks out for me is the fact that i wouldn't want my database to rely on the current inheritance structure of my application. if, for whatever reason, i wanted to change the design of my application in terms of inheritance, it wouldn't matter because my data wouldn't be reliant on my current system design. i think of data storage as just that--storage. the database is normalized according to proper database design, but inheritance is a programatic choice of application development, not data storage. that alone would prevent me from using it. inheritance is a very difficult thing to do properly when it comes to designing an application. it's much easier to change application code than it is to change and migrate database data
when most less-seasoned devs approach a problem they approach it with inheritance. i did too when i first started developing. it logically makes sense. however once developing for a long time you learn that delegation is really the best way to go (services calling services in the case of soa) and that single-purpose services provide a lot more reuse than inheritance."
Which also makes sense to me.
So
1) In general, what are the pros/cons of inheritance vs extending
2) In my specific example above, what would be more appropriate?
3) If my example is crappy for either or both, what is a good example for using inheritance and for using extending?
I've used both before but as I am far from seasoned, I am still unsure how to handle all situations.
10 Votes, 8 favorited, over a hundred views and no one can expand? =(.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我参加聚会有点晚了，但我一直对 EF 中的继承有与您相同的问题，并找到了一个非常好的摘要供您阅读。这是一个摘自 Julie Lerman 的《编程实体框架》一书。
读完后，我对此主题的结论如下：
1) 一般来说，继承与扩展的优点/缺点是什么 - 优点实际上取决于您选择的表策略。请参阅如何选择继承策略 - MSDN 博客。然而，它们只是在您已经决定使用继承的假设下才是“优点”。这并不是一个轻易做出的决定。
缺点有很多，但最大的缺点是无法将现有实体作为派生实体添加到数据库中。例如：我有一个继承自 Person 的 Student。有 John Smith 的人员记录。一段时间后，我需要约翰·史密斯成为一名学生。好吧，太糟糕了。那是不可能的。 （至少在没有使用存储过程规避 EF 的情况下是这样）。
2) 在上面的具体示例中，什么更合适？ - 在您的示例中，您应该将这些列（entityId、datecreated、datemodified）添加到需要它们的表中。您可以使用复杂类型来创建日期和修改日期，但这不是必需的，除非您是一个非常严格的 DRY 人。即便如此，这也可能有些过分了。原因是，一旦拥有实体，就永远无法将该实体添加到另一个派生表中。稍后无法将 Person（这是 BaseEntity）添加为学生。此外，编写 LINQ 查询将比所需的复杂得多。亚历克斯已经证明了这一点。
3）如果我的示例对于其中一个或两个都很糟糕，那么使用继承和使用扩展的一个好例子是什么？ - 一般来说，如果你可以使你的基类型抽象，继承可能为你工作。但您仍然应该首先考虑其他选择。如果您的基本类型将在某处直接实例化，则只需使用组合即可。当实际查询和插入记录时，继承会变得非常麻烦。
总之，仅仅因为您可以在 EF 中进行继承并不意味着您应该这样做。如果您可以采用无继承设计，那么请务必这样做。
I'm a little late to the party, but I've been having the same questions as you regarding inheritance in EF and found a pretty good summary for you to read. It's an excerpt from Julie Lerman's book Programming Entity Framework.
After reading it, here's my conclusions on the topic:
1) In general, what are the pros/cons of inheritance vs extending - The pros really depend on the table strategy you choose. See How to choose an Inheritance Strategy - MSDN Blog. However, they are only "pros" on the assumption that you have already decided to use inheritance at all. And that is not a decision to take lightly.
The cons are many, but the biggest is the inability to add an existing entity into the database as a derived entity. For example: I have a Student which inherits from Person. There is a Person record for John Smith. Some time later I need John Smith to be a Student. Well too bad. That's not possible. (At least not without circumventing EF with a stored procedure).
2) In my specific example above, what would be more appropriate? - In your example you should just add those columns (entityId, datecreated, datemodified) to tables that need them. You could use a Complex Type for datecreated and datemodified, but that wouldn't be necessary unless you're a very strict DRY guy. Even then, it might be overkill. The reason is that once you have an entity, you can never add that entity to another derived table. A Person (which is a BaseEntity) can not be added as a Student later. Also, writing LINQ queries would be far more complex than needed. Alex already showed that.
3) If my example is crappy for either or both, what is a good example for using inheritance and for using extending? - Generally, if you can make your base-type abstract, inheritance might work for you. But you should still consider other options first. If your base type will be directly instantiated somewhere, just use composition. Inheritance gets very troublesome when it comes to actually querying and inserting records.
In summary, just because you can do inheritance in EF does not mean you should. If you can get away with an inheritance-free design, then by all means do it.
我已经尝试过与您描述的类似的事情，我看到的主要问题是您无法为派生类型创建().ToList() 这样的查询，但我认为它不会在后台生成正确的 SQL，并且会首先获取完整的 BusinessObject 行，然后过滤掉内存中的 Person 实体。所以我想这会对性能产生巨大的影响。
ObjectSet。因此，您将没有ObjectSet存储库。如果您从 BusinessObject 实体等派生所有实体，则您将只能使用
ObjectSet。如果您只想查询 Person 存储库，您可以编写像 Context.BusinessObjectSet.OfTypeI have tried similar thing as you describe, and the main problem I see, is that u can't create
ObjectSet<T>for derived type. So you will not haveObjectSet<Person>repository.If you derive all your Entities from for example BusinessObject entity, you will be able to work only with
ObjectSet<BusinessObject>. If you want to query only Person repository, you can write query likeContext.BusinessObjectSet.OfType<Person>().ToList()but i think it will not generate proper SQL under the hood and will first get full BusinessObject rows and then filter out Person entities in memory. So I guess it will have huge performance impact.在模型中使用继承的一个缺点是，您将无法通过 WCF 数据服务 (OData) 显示模型，因为它当前不支持派生实体。
One disadvantage of using inheritance in your model is that you won't be able to surface your model through WCF Data Services (OData) as it doesn't currently support derived entities.