Миграция с «нативной» OODBMS на ORM (Entity Framework / SQL Server)

Question

Некоторое время назад мы начали разработку нового проекта, в котором имеется около 25-30 различных классов / типов / моделей, которые тесно связаны друг с другом через отношения 1: n, n: m или n: 1.

Тогда мы пошли с нативной системой .net oodbms в основном потому, что она позволила нам взять нашу объектную модель и просто добавить несколько методов, связанных с постоянством (-calls), здесь и там, и мы были готовы к работе. Однако с течением времени мы сталкивались с большим и большим количеством предостережений, действительно плохих, не поддающихся исправлению (в разумные сроки) ограничений, которые вынуждали нас внедрять медленные обходные пути, что приводило к посредственным проблемам производительности и масштабируемости на горизонте, и лицензионные отчисления почти выросли на фактор 5 для нас без изменений с нашей стороны (они были куплены большим инк.).

Поэтому в настоящее время мы начинаем искать долгосрочное решение с точки зрения масштабируемости / производительности, а также обслуживания. Мы взглянули на другие «настоящие» oodbms и всегда сталкивались с основными препятствиями для нас, и поэтому мы начали смотреть немного дальше и теперь в основном думаем об ORM, которые, мы надеемся, позволят нам сосредоточиться на наших объектах. спорить с SQL.

Так что в основном вот мой вопрос: есть ли у кого-нибудь реальный опыт работы с Entity Framework Microsoft или любым другим .NET ORM, который поддерживает конфигурацию настолько удобной, насколько это возможно, а также хорошо работает в тесно / сильно связанных объектах? Объем данных, которые мы храним, не является ни удивительным, ни обширным в каком-либо виде (мы ожидаем, что в общей сложности 100 000 экземпляров по всем объектам в течение следующих 3 лет).

Есть ли у кого-нибудь идеи / предложения для ORM и / или опыт перехода с oodbms на rdbms?

Answer 1

Поскольку у вас есть существующая объектная модель и вы хотите перейти на решение ORM, я бы сказал, что NHibernate, безусловно, будет хорошим выбором. И вот почему:

1. Вам не придется вносить (m) какие-либо дополнения / изменения в классы модели вашего домена, чтобы поддерживать постоянство. NHibernate имеет большое значение для поддержки постоянного невежества в модели вашего домена, хотя вы можете обнаружить, что вам нужно внести некоторые незначительные изменения, такие как пометка большего количества методов / свойств как виртуальных, чем, например, в противном случае.
2. После сопоставления существующей объектной модели вы можете сгенерировать схему для вашей базы данных. Это значительно экономит время на разработку, управляемую доменом (или только сначала объектной моделью). Эта функциональность поддерживается с помощью метода FluentConfiguration.ExposeConfiguration () с свободно распространяемым NHibernate или с помощью инструмента hbm2ddl со стандартными файлами сопоставления NHibernate. Это также, конечно, помогает с удобством сопровождения - изменения в вашей объектной модели могут быть быстро отражены в вашей схеме базы данных.
3. Использование беглого NHibernate для сопоставления помогает сделать начальное сопоставление достаточно быстрым, поскольку вы получаете автозаполнение и упрощенную модель сопоставления. Это также поможет вам обеспечить удобство сопровождения, которое вы ищете - ваше отображение объявлено в коде с помощью свободного NHibernate, поэтому инструменты рефакторинга изменят ваше отображение соответствующим образом. Вы также можете обнаружить, что можете использовать автоматическое сопоставление Fluent NHibernate и по большей части избегать ручного сопоставления вашей объектной модели.

Использование Entity Framework для этого будет более сложным. Хотя сущностная структура является во многих отношениях способной ORM, она не настолько зрелая, как NHibernate, и в этом случае есть несколько причин, в частности, почему я думаю, что это, вероятно, не лучший выбор:

1. Вам потребуется внести множество изменений в существующую объектную модель для поддержки Entity Framework. Если вы хотите использовать предоставляемые в настоящее время инструменты для платформы сущностей, вам, вероятно, потребуется перенести код в сгенерированные частичные классы, которые наследуются от базового класса платформы сущностей EntityObject. Это требование наследования может или не может быть проблемой для вас в зависимости от вашей существующей объектной модели. Вы могли бы избежать этого, поддерживая некоторые интерфейсы в своем коде, но это нетривиально, и я думаю, что вы потеряете много встроенной инструментальной поддержки для управления вашими отображениями.
2. Вам почти наверняка потребуется вручную создать схему базы данных. С объектной моделью хорошего размера это, как правило, несущественная задача.
3. Каркас сущностей не поддерживает прозрачную отложенную загрузку из коробки. Я уверен, что прозрачная отложенная загрузка - это то, к чему вы привыкли с OODBMS, и она поддерживается большинством других ORM (включая, конечно, NHibernate), но с структурой сущностей вы обнаружите, что вам нужно явно .Load () связанные объекты (родительские и дочерние отношения), прежде чем ссылаться на них в своем коде. Для этого есть обходные пути (например, , этот ), но это не встроенная функция.

В целом, на мой взгляд, для объектно-ориентированной разработки или там, где вы пытаетесь использовать существующую объектную модель, NHIbernate является лучшим выбором. Для событий, ориентированных на данные, Entity Framework (или linq to sql, или даже дозвуковой) становится более жизнеспособным выбором.

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

Answer 2

У меня нет опыта работы с OODBMS, но мой опыт работы с NHibernate + MS SQL Server был очень положительным с точки зрения принудительного и каскадного изменения: один-ко-многим, многие-к-одному и многие-к-одному много отношений.

Какой инструмент OODBMS вы используете? Возможно, существует инструмент миграции OODBMS -> RDBMS, но я не знаю ни одного.