NHibernate на устаревшей БД

Question

Мне стыдно это говорить, но я должен. Я не работал с ORM. Я действительно рассматриваю NHibernate, так как он кажется самым зрелым продуктом для .Net (пожалуйста, поправьте меня, если я не прав). Теперь дело в том, что у нас есть большая система электронной коммерции / бронирования с SqlServer в качестве основной точки интеграции, содержащая довольно много бизнес-логики в sprocs. Теперь - очевидно - эта архитектура - это то, от чего мы хотим отойти, и мы делаем это в течение некоторого времени, шаг за шагом. Итак, мой реальный вопрос: насколько реально начать использовать NHibernate для новых функций, а не возвращаться и наносить на карту все устаревшие вещи? Поддерживается ли этот вид постепенного внедрения и ORM, и если да, то вы бы порекомендовали его?

Answer 1

Если вы используете устаревшие базы данных, вы найдете инструменты ORM довольно сложными в использовании, настройке, обслуживании и оптимизации. Мы столкнулись со многими проблемами, когда использовали NHibernate для сопоставления нашей доменной модели с существующей базой данных. Некоторые из них были:

1. Объекты модели было трудно сопоставить с существующими таблицами (у нас было более 100 таблиц), некоторые требования NHibernate были довольно навязчивыми, так как каждая таблица должна иметь поле идентификатора, чтобы иметь возможность сопоставления с объектом Domain , Кроме того, сопоставление многих со многими отношениями было довольно трудно понять и использовать.

2. Поддержание большого объема сопоставление XML требуется для сопоставления с устаревшая база данных стала полноценной работа для разработчика и была довольно вызов, особенно в команде 10+ разработчиков.

3. Производительность наших запросов снижалась по мере роста сложности, поскольку модель данных и объектная модель не всегда соответствовали бизнесу и требовали постоянной настройки. Большой объем кода агрегации данных должен был быть написан. Например, если нам нужно было показать сетку, объединяющую несколько таблиц, мы обычно загружали несколько объектов Domain, складывали их вместе и отображали в одной сетке. Этот код было сложно поддерживать и отлаживать.

4. Кроме того, иногда нам приходилось запускать анонимные запросы, то есть когда мы просто хотели получить несколько свойств от некоторых объектов, а не от целых объектов. Это было действительно сложно писать, поддерживать и даже реализовывать, и это противоречило парадигме ORM, но у нас не было другого выбора, кроме как сделать это.

5. Другая проблема, с которой мы столкнулись, заключалась в том, что база данных постоянно менялась, поскольку администраторы баз данных реорганизовывали таблицы, и это всегда нарушало наши объекты домена. Это было упражнение, чтобы синхронизировать модели и таблицы, а также убедиться, что приложение все еще работает.

Короче говоря ... То, что мы узнали, что если бы был способ сопоставить SQL, который нужен бизнесу, прямо с объектами UI Model или Domain, не беспокоясь о конфигурации, это было бы лучшим решением.

После прохождения этого опыта мы разработали Orasis Mapping Studio. Это инструмент отображения, специально разработанный для работы с устаревшими базами данных, а также с существующими объектами .NET Model / Domain. Он принимает ваши запросы SQL и позволяет вам сопоставить их с вашими существующими объектами .NET, графически отображая метаданные запроса и объекта и используя перетаскивание для создания сопоставлений между свойствами объекта и столбцами запроса. Инструмент автоматически генерирует весь код ADO.NET, который вам понадобится для сопоставления ваших объектов. Затем вы можете использовать сгенерированный код на вашем уровне DAL или использовать сгенерированную сборку для извлечения и сохранения ваших данных.

Вы можете попробовать это здесь: Orasis Mapping Studio . Это инструмент, который, на наш взгляд, действительно нужен разработчикам, особенно для работы с устаревшими базами данных, где производительность является ключевым требованием. Он написан разработчиками для разработчиков, поэтому он обрабатывает некоторые сложные детали, такие как наследование объекта, вложенные объекты, преобразования типов данных и т. Д. Удачи!

Answer 2

Это будет зависеть от того, насколько "NHibernate friendly" ваша текущая база данных. NHibernate любит первичные ключи одного столбца (если они все названы "id", даже лучше). Насколько я знаю, большинство ORM не очень удобны для хранения. Задумывались ли вы о том, как вы будете определять свои объекты передачи, чтобы получать данные туда и обратно из БД?

Кстати, нечего стыдиться. ORM - это глупость, но вы правы, пытаясь найти лучший подход.

Answer 3

Я согласен с тем, что сказал Ахмад, в прошлом я сталкивался с подобными проблемами. Большинство проблем, которые я получил, были связаны не с самой технологией, а с ее принятием разработчиками, поэтому переход на NHibernate подразумевает изменение рабочих привычек, если не сказать больше, и это не всегда легко.

Если вы новичок в ORM, возможно, лучше начать с него совершенно новый проект, чем пытаться преобразовать устаревший проект.

Мой совет по преобразованию унаследованного проекта в ORM - попытаться использовать какой-либо инструмент генерации, такой как LLBGen или .netTiers, или даже Linq2SQL. Таким образом, вы могли бы чувствовать себя немного комфортнее с ORM без травматического переписывания, которое может навязать NHibernate.

Answer 4

Вы упомянули, что уходите от своей текущей архитектуры, но обязаны ли вы придерживаться своей прежней конструкции базы данных (например, администратор базы данных несет полную ответственность за ее разработку и обслуживание), или же ваша структура базы данных подвергается реорганизации (с учетом для картографа O / R)?

Если вам трудно отойти от вашего текущего унаследованного проекта, вы, вероятно, могли бы рассмотреть что-то еще, например iBATIS SqlMap для отображения объектов O / R в вашу унаследованную базу данных с использованием простых старых запросов T-SQL а не менее гибкие XML / атрибуты в стиле Hibernate для сопоставления данных.

В зависимости от того, как вы хотите приблизиться к дизайну, вы можете использовать iBATIS SqlMap и NHibernate прозрачно бок о бок, используя собственную абстрактную фабрику DAO , или API iBATIS DataAccess (который по сути делает это и по-прежнему совместим с NHibernate.)

Answer 5

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

Самой большой проблемой в этом случае может быть приведение ваших устаревших структур таблиц в соответствие с методологией таблицы NHibernate для каждого класса. Есть способы обойти это, но это может быть сложно. Тем не менее, я думаю, что это стоит.

Answer 6

Любой приличный инструмент ORM должен поддерживать постепенную интеграцию. Хитрость заключается в том, чтобы иметь четкое разделение на уровне DAO (уровень доступа к данным). Если вы можете скрыть свои особенности доступа к данным с помощью четко определенного API, не должно иметь значения, используете ли вы ORM или нет.

С учетом вышесказанного, сложность введения в ORM напрямую связана со сложностью моделей ваших таблиц. У вас может быть много разных отображений для одних и тех же таблиц, просто убедитесь, что вы предварительно выполнили несколько испытаний, чтобы узнать причуды решения ORM, такие как наличие кеша объектов, запросов обратной записи, прокси-доступа и тому подобное. Настоящим преимуществом решения ORM является использование объектов вместо фиктивных классов POJO. Это делает внесение изменений в бизнес намного проще, чем использование звездочек или плоских объектов.

Как примечание, я работал над проектом, в котором мы переместили целое приложение в sprocs на java. Хотя мы не использовали sproc, реальная боль заключалась в том, что архитектура sprocs не была четко определена, из-за большого количества sprocs, вызывающих другие sprocs, было очень трудно мигрировать только несколько sprocs за раз.

Answer 7

Я лично этого не делал, но вы можете скопировать и вставить хранимые процедуры в именованные запросы в файлы сопоставления и впоследствии удалить их один за другим.

Если у вас нет опыта работы с ORM, возможно, вам будет сложно начать изучать его в большом устаревшем проекте, потому что вам нужно обнаружить все нестандартные функции ORM, которые вы не использовали бы в проектах с нуля. или используйте только один раз в год. NHibernate имеет множество опций для поддержки устаревших баз данных.

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

Answer 8

Почему хранимые процы "явно" плохи? Вызывает ли бизнес-логика в хранимых процессах боль?

Похоже, что у Microsoft имеется ряд постоянных технологий (например, LINQ). Я не знаю, как их сравнить с NHibernate, но я бы не рекомендовал ORM, если у вас нет действительно хороших объектов для сопоставления.