实体类;类同类遗产问题 [英] Classes to Entities; Like-class inheritence problems

问题描述

除了工作之外，有些朋友和我正在尝试建立一种游戏;我们构造其中的一些方法对于面向对象的正常方法来说非常有用，但是由于大多数开发人员将证明这一点并不总是将自身转化为数据库持久化方法。

这不是我们所拥有的绝对布局，它只是为了表示而给出的示例模型。

整个项目正在C＃4.0中完成，我们有意使用Entity Framework 4.0（除非Fluent nHibernate真的能为我们提供我们完全不能在EF中做的事情）。

我们继续运行的一个问题是继承数据库模型中的东西。使用实体框架设计器，我可以绘制与下面相同的代码;但是我相信这是很明显的，它不会像预期的那样工作。

澄清一点; 物品有奖金，这可以是任何东西。因此，游戏的每个部分都必须从类似的东西中获得，所以无论什么是改变，都是在一个基本足够的水平上被吸引。听起来相当简单直接，对吗？

那么，我们继承从单位到游戏的一切。权重，度量，随机（想像骰子，也许？），还有其他这样的实体。其中一些是相似的，但在代码中，它们各有不同的反应。

我们将这种事情抽象成数据库模型有一个很大的问题。没有枚举支持，证明很难将它们转换为仍然共享一个列表的多个表。我们描述的一个解决方案是使用键环类型方法，其中附加到字符的所有内容都存储在带有键的环上，其中每个键都有一个表示类型的值。这在功能上有效，但我们发现它变得非常缓慢，表现不佳。我们也不喜欢这种方法，因为它开始感觉到一切都被倾倒成一类;这使得管理和逻辑结构难以遵守。

我希望有人可能有一些想法可以解决这个问题。真的把我推开了墙;要总结;目标是在相对全局的范围内构建一个类型（Unit），该类型可用作通用引用的基类型（Table per Type），而无需将所有内容转储到单个集合中。我可以使用界面来确定实际的行为，这不是一个问题太大。

alt text http://img171.imageshack.us/img171/5153/modelg.png

这在实体框架中表达的是同样的想法。

alt text http：/ /img684.imageshack.us/img684/6454/entities.png

解决方案

你是否尝试过一个混凝土表单位类型映射即使用Id字段链接度量，重量和随机表？ （每个都有一个Id列，它们是通过这个相关的。）

我认为在Sheet和Measure之间显示的关系将在每个类映射的表中有问题。如果单位度量的类型类型由单位中的标识符列确定，则表格不能映射到措施。使用TPCT，您可以成功地将Sheet映射到度量，因为它可以使用Id来恢复到单位表。

不幸的是，TPCT的例子很少：有时似乎需要几次迭代{编辑模型，导出数据库，修改SSMS，导入数据库} ...以使其正确。

Beyond work, some friends and I are trying to build a game of sorts; The way we structure some of it works pretty well for a normal object oriented approach, but as most developers will attest this does not always translate itself well into a database persistent approach.

This is not the absolute layout of what we have, it is just a sample model given for sake of representation.

The whole project is being done in C# 4.0, and we have every intention of using Entity Framework 4.0 (unless Fluent nHibernate can really offer us something we outright cannot do in EF).

One of the problems we keep running across is inheriting things in database models. Using the Entity Framework designer, I can draw the same code I have below; but I'm sure it is pretty obvious that it doesn't work like it is expected to.

To clarify a little bit; 'Items' have bonuses, which can be of anything. Therefore, every part of the game must derive from something similar so that no matter what is 'changed' it is all at a basic enough level to be hooked into. Sounds fairly simple and straightforward, right?

So then, we inherit everything that pertains to the game from 'Unit'. Weights, Measures, Random (think like dice, maybe?), and there will be other such entities. Some of them are similar, but in code they will each react differently.

We're having a really big problem with abstracting this kind of thing into a database model. Without 'Enum' support, it is proving difficult to translate into multiple tables that still share a common listing. One solution we've depicted is to use a 'key ring' type approach, where everything that attaches to a character is stored on a 'Ring' with a 'Key', where each Key has a Value that represents a type. This works functionally but we've discovered it becomes very sluggish and performs poorly. We also dislike this approach because it begins to feel as if everything is 'dumped' into one class; which makes management and logical structure difficult to adhere to.

I was hoping someone else might have some ideas on what I could do with this problem. It's really driving me up the wall; To summarize; the goal is to build a type (Unit) that can be used as a base type (Table per Type) for generic reference across a relatively global scope, without having to dump everything into a single collection. I can use an Interface to determine actual behavior so that isn't too big of an issue.

alt text http://img171.imageshack.us/img171/5153/modelg.png

This is 'roughly' the same idea expressed in the Entity Framework.

alt text http://img684.imageshack.us/img684/6454/entities.png

解决方案

Have you tried a Table per Concrete Type mapping for Unit? i.e. using the Id field to link the Measure, Weights and Random tables? (each has an Id column and they are related through this.)

I think the relationship you show between Sheet and Measure is going to be problematic in a Table per class mapping. Sheet can't map to just Measures if the type type of unit 'measure' is determined by a discriminator column in Units. With TPCT you can map Sheet to Measures successfully because it can use the Id to 'get back' to the Units table.

Unfortunately there's very little by way of examples for TPCT: sometimes it seems to take a few iterations of {edit model, export database, make changes in SSMS, import database} ... to get it right.

这篇关于实体类;类同类遗产问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！