В CL, Постмодернистском, что: тип седла для использования для Многих для поля Many?

ORMs раздуваются для того, чтобы быть решением проблем Доступа к данным. Лично, используя их в Проекте Предприятия, они далеки от того, чтобы быть решением для Разработки Корпоративного приложения. Возможно, они работают в маленьких проектах. Вот проблемы, которые мы испытали с ними конкретно nHibernate:

1. Конфигурация: технологии ORM требуют, чтобы конфигурационные файлы отобразили схемы таблицы в структуры объекта. В системах крупного предприятия конфигурация растет очень быстро и становится чрезвычайно трудной создать и справиться. Поддержание конфигурации также становится утомительным и неудобным в сопровождении как бизнес-требования, и модели постоянно изменяются и развиваются в гибкой среде.

2. Пользовательские запросы: способность отобразить пользовательские запросы, которые не вписываются ни в какой определенный объект, или не поддерживается или не рекомендуется поставщиками платформы. Разработчики вынуждены найти, что обходные решения путем записи для данного случая возражают и запрашивают, или записи пользовательского кода для получения данных, в которых они нуждаются. Им, вероятно, придется использовать Хранимые процедуры регулярно для чего-либо более сложного, чем простой Выбор.

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

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

5. Производительность: уровни ORM используют отражение и самоанализ, чтобы инстанцировать и заполнить объекты с данными из базы данных. Они - дорогостоящие операции с точки зрения обработки и добавляют к снижению производительности операций отображения. Объектные Запросы, которые переводятся для создания неоптимизированных запросов без опции настройки их вызывающий значительные потери производительности и перегружающийся систем управления базами данных. Производительность, настраивающая SQL, почти невозможна, так как платформы обеспечивают мало гибкости по управлению SQL, который автоматически генерируется.

6. Плотное соединение: Этот подход создает трудную зависимость между объектами модели и схемами базы данных. Разработчики не хотят непосредственную корреляцию между полями базы данных и полями класса. Изменение схемы базы данных имеет слегка колеблющееся влияние в объектной модели и отображающейся конфигурации и наоборот.

7. Кэши: Этот подход также требует использования объектных кэшей и контекстов, которые необходимы для maintian и отслеживают состояние объекта и уменьшают распространения в прямом и обратном направлениях базы данных для кэшированных данных. Эти кэши, если не сохраняемый и synchrnonized в многоярусной реализации может иметь значительные разветвления с точки зрения точности данных и параллелизма. Часто сторонние кэши или внешние кэши должны быть включены для решения этой проблемы, добавив обширную нагрузку для уровня доступа к данным.

Для получения дополнительной информации о нашем анализе можно читать: http://www.orasissoftware.com/driver.aspx?topic=whitepaper