我刚刚开始为新的C＃项目建模数据，该项目必须是可持久的。
看起来最自然的OO模型会有很多嵌套的.Net泛型。对象列表和这些对象还将包含其他泛型类型的列表，依此类推，至少嵌套三个级别。
理想情况下，我想以OO方式设计数据模型，让对象关系映射工具处理持久性 - 对我而言，OO设计比关系设计更容易。
但我对ORM的初步研究表明，他们不一定以这种方式工作。我还不清楚我是否可以创建任何任意复杂的对象模型，并期望ORM“自动地”持久化它。 （我昨天问了这个问题）。
我的印象是，我可能不得不将我的OO数据模型限制为我知道ORM可以处理的构造，这似乎是一个很大的限制，特别是当我还没有决定使用ORM时。
我希望让项目设计继续前进，并且不想陷入研究ORM的困境。
我的直觉就是围绕我所知道的C＃设计我的对象模型，这种方式看似最自然。这将有助于我更好地了解应用程序的真正需求。我希望我可以根据ORM限制重新设计设计，如果证明是必要的话。
这是一个好方法，还是我为自己创造了一个受伤的世界？是否更好地预先处理已知的ORM约束，并围绕这些约束“愚弄”对象模型？
编辑：未经请求的Stefan Steinegger列出了NHibernate对OO代码施加的大部分限制。其他人可以为其他ORM提供类似的列表 - 特别是亚力士吗？
答案 0 :(得分：2)
决定将模型映射到关系数据库的容易程度仍然在很大程度上取决于将要使用的ORM。
我对NHibernate有一些经验。这是我迄今为止看到的最灵活，最具侵入性的ORM（尽管我没有看到很多）。所以我可以谈谈NHibernate，即使你不会使用它，它会给你一些你应该期待的印象。
我们几乎可以自由地设计类模型。实施细节中的限制更多：
IList<T>，ICollection<T>，IDictionary<K, V>，数组，其他一些接口或非通用对应物。当具有多态的值类型类（没有自己的身份并且被“值”处理）时，你应该小心。必须要成为实体（需要身份）才能实现这一目标。
我记不起我们在NHibernate中对类模型的任何其他限制。
答案 1 :(得分：1)
我对其他ORM不太了解，但你应该用NHibernate这样做。它的目的是这样使用：首先以DDD方式设计您的域，稍后关心数据库和与持久性相关的东西。 可能在引入NH时需要一些（次要的）重构，但如果你有一个设计合理的领域模型，那么根据我的经验并不是什么大问题，而且它们肯定不会让你感到痛苦。
答案 2 :(得分：1)
我认为真正的问题是如何开发我的OO应用程序，并且仍然能够将其数据（对象）保存在关系存储中，无论ORM还是ORM。您应该完全关注对象模型，直到达到实际音量，阻抗不匹配可能会对您造成伤害。在不考虑系统的关系模型的情况下，仍然无法开发任何关系数据库支持的系统，无论是否OO。
此外，对象模型中唯一需要“缩减”的类是持久化的类。所有其他人都可以像您希望的那样复杂和复杂。