OO модель данных - могу ли я игнорировать ограничения Object Relational Mapper?

Question

Я только начинаю моделировать данные для нового проекта C #, который должен быть постоянным.

Похоже, что самая естественная модель ОО будет иметь множество вложенных обобщенных шаблонов .Net. Списки объектов, и эти объекты также будут содержать списки других универсальных типов и т. Д., Вложенные по крайней мере на три уровня.

В идеале, я хотел бы просто спроектировать модель данных в режиме OO и позволить инструменту Object Relational Mapping справиться с упорством - для меня OO-дизайн гораздо проще, чем реляционный дизайн.

Но мое первоначальное исследование ORM показывает, что они не работают таким образом. Мне пока не ясно, смогу ли я просто создать произвольно сложную объектную модель и ожидать, что ORM сохранит ее "автоматически". (Я задал этот вопрос вчера).

У меня сложилось впечатление, что мне, возможно, придется ограничить свою модель данных OO конструкциями, которые, как я знаю, может обрабатывать ORM, что кажется большим ограничением, особенно когда я еще не выбрал ORM.

Я хочу продолжать разработку проекта и не хочу увязать в исследовании ORM прямо сейчас.

Мой инстинкт состоит в том, чтобы просто проектировать мою объектную модель вокруг того, что я знаю, что я могу сделать в C #, способом, который кажется наиболее естественным. Это поможет мне лучше понять, что действительно требуется для приложения. Я надеюсь, что затем смогу пересмотреть дизайн на основе ограничений ORM, если это окажется необходимым.

Это хороший подход, или я готовлюсь к миру зла? Лучше ли иметь дело с известными ограничениями ORM заранее и «притупить» объектную модель вокруг этих ограничений?

Редактировать: Незаинтересованный Стефан Штайнеггер перечислил большинство ограничений, которые накладывает NHibernate на код OO. Может ли кто-нибудь еще предоставить аналогичный список для других ORM - в частности, Subsonic?

Answer 1

Чтобы решить, насколько просто будет сопоставить вашу модель с реляционной базой данных, все еще сильно зависит от ORM, который будет использоваться.

У меня есть некоторый опыт работы с NHibernate. Это самый гибкий и ненавязчивый ORM, который я видел до сих пор (хотя я не видел многих из них). Так что я могу говорить о NHibernate, даже если вы не будете использовать его, он даст вам некоторое представление о том, чего вы должны ожидать.

Мы почти свободно проектируем модель класса. Ограничения больше в деталях реализации:

• вам нужен конструктор по умолчанию (может быть приватным)
• коллекции должны иметь тип IList<T>, ICollection<T>, IDictionary<K, V>, Array, несколько других интерфейсов или его неуниверсальные аналоги.
• все должно быть виртуальным, чтобы сделать возможной отложенную загрузку. (необязательно, но настоятельно рекомендуется)
• каждому объекту (не тип-значение) требуется свойство первичного ключа базы данных и свойство версии базы данных для оптимистической блокировки (необязательно, но настоятельно рекомендуется)

Вы должны быть осторожны, имея классы типа значения (не имеющие собственной идентичности и обработанные «по значению»), которые являются полиморфными. Вероятно, чтобы сделать это возможным, необходимо стать субъектами (нуждающимися в идентификации).

Я не могу вспомнить какие-либо другие ограничения, которые у нас были в NHibernate в отношении модели класса.

Answer 2

Я думаю, что реальный вопрос заключается в том, как я могу разработать свое ОО-приложение и при этом сохранять его данные (объекты) в реляционном хранилище независимо от ORM или без ORM. Вы должны быть в порядке с вашим подходом строго относиться к вашей объектной модели, пока не достигнете реального объема, где несоответствие импеданса может повредить вам. По-прежнему невозможно разработать какую-либо систему, поддерживающую реляционную базу данных, не задумываясь о реляционной модели системы, будь то ОО или нет.

Кроме того, единственные классы в вашей объектной модели, которые необходимо «отключить», - это те, которые подвержены постоянству. Все остальные могут быть настолько сложными и сложными, насколько вы пожелаете.

Answer 3

Я не слишком много знаю о других ORM, но вы обязательно должны пойти по этому пути с NHibernate. Он предназначен для использования в точности так: сначала спроектируйте свой домен в DDD-стиле, потом позаботьтесь о базе данных и прочем. Возможно, что некоторые (незначительные) рефакторинги становятся необходимыми при внедрении NH, но, по моему опыту, это не имеет большого значения, если у вас правильно спроектированная модель предметной области, и они, конечно, не болезненны.