Хочу ли я ОРМ?

Question

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

Сейчас программы просто используют общую библиотеку для заполнения объектной модели и сериализации / десериализации на диск.В частности, мы используем сериализацию XML.

Есть несколько проблем с этой моделью.1) XML можно считать расточительным.Файлы могут стать большими и громоздкими.Честно говоря, размер файла не является большой проблемой сейчас.2) Больше всего меня беспокоит отпечаток памяти.Весь файл загружается в объектную модель, обрабатывается, затем сохраняется.

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

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

Мы рассмотрели NHibernate с SQLite, SQL Compact 4.0 и EF 4 и LINQ.в XML (кратко).В прошлом я также использовал db4o для кэширования объектов на диск, но это был не связанный проект.

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

Существуют ли другие технологии, которые могут мне помочь?Файлы, отображаемые в память, linq-to-sql, Lazy (T) (только для извлечения объектов из файлов при необходимости).

Я понимаю, что это открытый вопрос.Я ищу подробный ответ и подробности, если кто-то там имеет реальный опыт в этом деле.Ссылки были бы полезны ...

Спасибо.

Answer 1

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

Answer 2

Я только что закончил миграцию (в основном «унаследованного») веб-приложения, поддерживаемого файлами XML, на NHibernate именно из-за той же проблемы.Я также был в той же ситуации, что никогда раньше не использовал NHibernate и хотел учиться в процессе.Идея имеет смысл.Вы действительно сможете загружать в память только те части, которые вам действительно нужны (в отличие от всей БД), и гораздо больше преимуществ, чем это.

Основываясь на других вещах, которые вы просите (минимальные изменения в вашей объектной модели, простой переход с реальных приложений на ORM), я не уверен, что вы получите их так легко.С ORM, такими как NHibernate и EF4, классы моделей очень легковесны: они в основном немного больше, чем контейнеры свойств.Приложения, основанные на файлах XML, как правило, имеют больше логики непосредственно в модели: эту логику вам, вероятно, придется перенести на уровень доступа к данным.Редизайн модели и слоя доступа к данным, вероятно, будет самой трудоемкой задачей, с которой вы столкнетесь.Я знаю, что это было для меня.

Другая вещь, которую я заключаю из вашего вопроса (вы говорите, что все три программы не могут общаться с одной и той же БД, и вы упоминаете SQLite и SQL Compact), это то, что вы реплицируетеваши данные среди ваших трех приложений путем физического копирования файла.Как вы обнаруживаете изменения и насколько выровнены вам нужно 3 БД?Как вы в настоящее время объединяете изменения (в случае, если 2 из 3 ваших приложений могут записывать данные)?В зависимости от того, как вы копируете данные, ORM может помочь вам, а может и не помочь.

Редактировать еще несколько точек на основе ваших комментариев

• Если вы хотите в какой-то момент объединить файлы в одну БД, и вы еще не уверены в этомбудет продукт Microsoft, тогда NHibernate является лучшим выбором.Но если вы сейчас активно используете LINQ (согласно другому из ваших комментариев) и хотите более плавный переход, я бы остановился на EF4: Nhibernate.Linq не совсем завершен, а некоторые конструкции не работают.
• Как NHibernate, так и EF4 очень хорошо документированы и содержат очень хорошие учебные пособия о том, как создать законченное приложение с нуля, так что обучающая часть действительно проста.
• Оба имеют «модель в первую очередь»подход, при котором вы получаете инструмент, который создает вашу БД для вас на основе ваших классов моделей, поэтому, если ваши классы моделей очень легкие, вы сможете использовать их с небольшими изменениями.
• вещь, которая заняла у меня некоторое время(и все же иногда мне трудно работать) в NHibernate настраивает каскады так, как я ожидал: например, что происходит со «связанными» объектами при удалении объекта?

Answer 3

Мое предложение заключается в том, что вы используете базу данных документов. RavenDB даст вам много преимуществ.Вы сможете хранить объекты, не конвертируя их в реляционную модель, как это делает db4o.

Однако, с RavenDB у вас есть очень богатая возможность запрашивать данные с помощью Map / Reduce.Еще одним преимуществом является то, что он написан с использованием .NET для .NET, поэтому вам понравится делать запросы в Linq.Он может работать как служба Windows или в IIS.Он также может работать встроенным, что отлично подходит для тестирования.Это может быть хорошей идеей для ваших приложений сбора данных.

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

Однако, в зависимости от характера вашей распределенной настройки, я думаю, вам будет лучше использовать служебную шину.Нужно ли вам государство в приложениях сбора данных?Если нет, просто опубликуйте сообщение, содержащее данные на служебной шине, для использования другой частью системы.Это может звучать сложно, но на самом деле это не так.Взгляните на nServicebus .