Есть веские причины не использовать ORM? [закрытый]

короткий ответ-да, есть действительно веские причины. На самом деле есть случаи, когда вы просто не можете использовать ORM.

дело в том, что я работаю на крупное финансовое учреждение предприятия, и мы должны следовать многим рекомендациям по безопасности. Чтобы соответствовать правилам и положениям, которые на нас возложены, единственный способ пройти аудит-сохранить доступ к данным в рамках хранимых процедур. Некоторые могут сказать, что это просто глупо, но, честно говоря, это не так. Использование инструмента ORM инструмент/разработчик может вставлять, выбирать, обновлять или удалять все, что он или она хочет. Хранимые процедуры обеспечивают гораздо большую безопасность, особенно в средах при работе с клиентскими данными. Я думаю, что это самая большая причина для рассмотрения. Безопасность.

сладкое пятно ORMs

ORMs полезны для автоматизации 95% + запросов, где они применимы. Их особая сила заключается в том, что у вас есть приложение с сильной архитектурой объектной модели и базой данных, которая хорошо играет с этой объектной моделью. Если вы делаете новую сборку и имеете сильные навыки моделирования в своей команде, вы, вероятно, получите хорошие результаты с ORM.

У вас может быть несколько запросов, которые лучше вручную. В этом случае не бойтесь написать несколько хранимых процедур для обработки этого. Даже если вы собираетесь перенести приложение на несколько платформ СУБД, код, зависящий от базы данных, будет в меньшинстве. Учитывая, что вам нужно будет протестировать приложение на любой платформе, на которой вы собираетесь его поддерживать, немного дополнительных усилий по переносу для некоторых хранимых процедур не будет иметь большого значения для вашего TCO. Для первого приближения, 98% портативное как раз так же хорошо, как 100% портативный, и намного лучше, чем запутанные или плохо выполняющиеся решения для работы в пределах ORM.

Я видел, что первый подход хорошо работает на очень большом (100 лет персонала) проекте J2EE.

где ORM может быть не самым подходящим

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

• в приложении с существенной устаревшей кодовой базой хранимых процедур вы можете использовать функционально ориентированный (не путать с функциональными языками) уровень доступа к данным для обертывания действующих sprocs. Это повторно использует существующий (и, следовательно, протестированный и отлаженный) доступ к данным проектирование слоев и баз данных, которое часто представляет собой довольно значительную разработку и тестирование, и экономит время на переносе данных в новую модель базы данных. Это часто довольно хороший способ обернуть слои Java вокруг устаревших баз кода PL/SQL или переназначить богатые клиентские приложения VB, Powerbuilder или Delphi с веб-интерфейсами.

• вариант, где вы наследуете модель данных, которая не обязательно хорошо подходит для отображения O-R. Если (например) вы пишете интерфейс, который заполняет или извлекает данные из внешнего интерфейса, вам может быть лучше работать с базой данных.

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

• высокопроизводительных приложений где вы хотите действительно настроить доступ к базе данных. В этом случае может быть предпочтительнее работать на более низком уровне.

• ситуации, когда вы используете действующий механизм доступа к данным, как ADO.Net это "достаточно хорошо", и хорошая игра с платформой приносит большую пользу, чем ORM.

• иногда данные-это просто данные - это может быть случай (например), что ваше приложение работает с "транзакциями", а не "объектами" и что это разумный взгляд на область. Примером этого может быть пакет финансовых документов, в котором имеются проводки с настраиваемыми полями анализа. Хотя само приложение может быть построено на платформе O-O, оно не привязано к одной модели бизнес-домена и может не знать гораздо больше, чем коды GL, учетные записи, типы документов и полдюжины полей анализа. В этом случае приложение не знает о модели бизнес-домена как таковой и объектной модели (за пределами главной книги сама структура) не имеет отношения к применению.

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

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

1. Тестирование кода
2. поддержание вашего кода

решения для них:

1. сделайте свой код тестируемым (используя твердый принципы)
2. напишите автоматические тесты для как можно большей части кода
3. запускайте автоматические тесты как можно чаще

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

невозможность писать запросы SELECT вручную (что, я полагаю, является причиной необходимости копирования-вставки), похоже, указывает на настоятельную необходимость некоторого обучения SQL.

есть две причины, по которым я бы не использовал ORM:

1. это строго запрещено политикой компании (в этом случае я бы пошел работать в другое место)
2. проект очень Data intensive и использование конкретных решений для поставщиков (например, BulkInsert) имеет больше смысла.

обычные отказы от ORMs (в частности, NHibernate):

1. скорость

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

2. сложности

   Что касается сложности, использование ORM означает меньше кода, что обычно означает меньшую сложность. Многие люди, использующие рукописный (или сгенерированный код) доступ к данным, обнаруживают, что пишут свою собственную структуру над "низкоуровневыми" библиотеками доступа к данным (например, пишут вспомогательные методы для ADO.Net). Они приравниваются к большей сложности, и, что еще хуже, они редко хорошо документированы или хорошо проверены.
   Если вы смотрите конкретно на NHibernate, то такие инструменты, как Fluent NHibernate и Linq To NHibernate, также смягчают кривую обучения.

то, что меня заводит вся дискуссия об ORM заключается в том, что те же люди, которые утверждают, что использование ORM будет слишком сложным/медленным/что угодно, - это те же самые люди, которые более чем счастливы, используя Linq to Sql или типизированные наборы данных. Хотя Linq to Sql-большой шаг в правильном направлении, он по-прежнему отстает от некоторых ОРМ с открытым исходным кодом. Однако фреймворки как для типизированных наборов данных, так и для Linq to Sql по-прежнему чрезвычайно сложны, и использовать их, чтобы зайти слишком далеко от (Table=Class) + (basic CRUD) глупо трудный.

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

(Как это для разглагольствования?)

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

одной из сильных сторон Hibernate является то, что вы можете говорить только 3 раза: каждое свойство упоминается в классе .hbm.xml-файл и база данных. С запросами SQL ваши свойства находятся в классе, базе данных, операторах select, операторах insert, обновлении операторы, операторы delete и весь маршалинг и unmarshalling код, поддерживающий ваши SQL-запросы! Это может стать грязным быстро. С другой стороны, ты знаешь, как это работает. Вы можете отладить его. Все в порядке в вашем собственном слое настойчивости, а не в недрах стороннего инструмента.

Hibernate может быть постером-ребенком для закона Спольского о протекающих абстракциях. Отойдите немного в сторону от проторенного пути, и вам нужно знать глубокие внутренние работы инструмента. Это может быть очень раздражает, когда вы знаете, что вы могли бы исправить SQL за считанные минуты, но вместо этого вы тратите часы, пытаясь уговорить свой инструмент dang в создании разумного SQL. Отладка иногда является кошмаром, но трудно убедить людей, которые там не были.

EDIT: возможно, вы захотите посмотреть iBatis.NET если они не собираются разворачиваться вокруг NHibernate, и они хотят контролировать свои SQL-запросы.

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

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

1. должен был быть горизонтально scalealbe с самого начала
2. должен был быть разработан быстро
3. была относительно простая модель домена

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

Итак, в 90% проектов, над которыми я работал на ORM, была неоценимая помощь. Но есть некоторые очень специфические обстоятельства, когда я не вижу, как использовать ORM лучше всего.

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

Я обнаружил, что при проектировании систем с высокими требованиями к производительности мне часто приходится искать способы сделать систему более эффективной. Много раз я получаю решение с тяжелым профилем производительности записи (что означает, что мы запись данных намного больше, чем мы читаем данные). В этих случаях я хочу воспользоваться возможностями, которые предлагает мне платформа базы данных, чтобы достичь наших целей производительности (это OLTP, а не OLAP). Поэтому, если я использую SQL Server и знаю, что у меня много данных для записи, почему бы мне не использовать массовую вставку... ну, как вы, возможно, уже обнаружили, большинство ORMS (я не знаю, есть ли даже один) не имеют возможности воспользоваться преимуществами платформы, такими как bulk вставлять.

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

для нетривиального корпоративного приложения на основе базы данных действительно нет оснований не использовать ORM.

функции в сторону:

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

поставить некоторые перспективу в споре, изучить преимущества использования ADO.NET и писать код для анализа табличных данных собой поток.

Я видел, как незнание того, как использовать ORM, оправдывает презрение разработчика к ORMs, например: нетерпеливая загрузка (что-то, что я заметил, Вы не упомянули). Представьте, что вы хотите получить клиента и все его заказы, а также все детали заказа. Если вы полагаетесь только на ленивую загрузку, вы уйдете от своего опыта ORM с мнение: "Ормы медлительны."Если вы научитесь использовать eager loading, вы за 2 минуты сделаете с 5 строками кода то, что вашим коллегам потребуется полдня для реализации: Один запрос к базе данных и привязка результатов к иерархии объектов. Другим примером может быть боль от ручного написания SQL-запросов для реализации подкачки.

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

Не позволяйте опыту ваших старших членов команды тащить вас в противоположном направлении эволюции информатики. Я развиваюсь профессионально в течение 23 лет, и одна из констант-презрение к новому со стороны старой школы. ORMs для SQL, как язык C был для сборка, и вы можете поспорить, что эквиваленты C++ и C# уже в пути. Одна строка кода новой школы равна 20 строкам кода старой школы.

когда вам нужно обновить 50000000 записей. Установите флаг или что-то еще.

попробуйте сделать это с помощью ORM без вызов хранимой процедуры или собственных команд SQL..

Update 1: Попробуйте также получить одну запись только с несколькими ее полями. (Когда у вас очень "широкий" стол). Или скалярный результат. Ормы в этом тоже отстой.

обновление 2: кажется, что EF 5.0 beta обещает пакетные обновления, но это очень горячие новости (2012, Январь)

Я думаю, что, возможно, когда вы работаете над большими системами, вы можете использовать инструмент генератора кода, такой как CodeSmith вместо ORM... Я недавно нашел это:Cooperator Framework который генерирует хранимые процедуры SQL Server, а также генерирует ваши бизнес-объекты, картографы, шлюзы, lazyload и все такое в C#...это было написано командой здесь, в Аргентине...

Я думаю, что он находится посередине между кодированием всего уровня доступа к данным и использованием ОЗР...