Все здесь прыгают на универсале ORM?

Microsoft Linq to SQL, Entity Framework (EF), nHibernate и т. Д. Предлагают ORMS в качестве следующего поколения технологий отображения данных и утверждают, что они легки, быстры и просты. Как например эта статья, которая только что была опубликована в журнале VS:

http://visualstudiomagazine.com/features/article.aspx?editorialsid=2583

Кто все взволнован внедрением этих технологий в свои проекты? Где инновации в этих технологиях, которые делают их такими превосходными по сравнению с предшественниками?

12.12.2008 16:18:29
Astoria - это не ORM, а механизм доступа к данным, использующий REST / HTTP.
DamienG 14.12.2008 19:27:26
Вы правы, я уберу это.
Ahmad 17.12.2008 18:27:44
Я не использую этот материал, я сделал свой собственный: valueinjecter.codeplex.com/...
Omu 29.07.2010 11:53:02
19 ОТВЕТОВ
РЕШЕНИЕ

За эти годы я написал слои доступа к данным, компоненты персистентности и даже свои собственные ORM в сотнях приложений (одно из моих «хобби»); Я даже реализовал свой собственный менеджер бизнес-транзакций (обсуждался в SO).

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

Итог: я всегда предпочел бы сделать свой собственный доступ к данным, а не бороться с каким-то инструментом, который пытается «помочь» мне. Отказ от контроля над моей судьбой неприемлемо, и доступ к данным является важной частью судьбы моего приложения. Некоторые простые принципы делают доступ к данным очень управляемым.

Используйте базовые концепции модульности, абстракции и инкапсуляции - так что оберните базовый API доступа к данным вашей платформы (например, ADO.NET) своим собственным уровнем, который поднимает уровень абстракции ближе к вашему проблемному пространству. НЕ кодируйте весь доступ к данным ПРЯМО против этого API (также обсуждаемого в других разделах SO).

Строго следуйте принципу СУХОЙ (не повторяйте себя) = рефакторинг дневного света из вашего кода доступа к данным. Используйте генерацию кода, когда это уместно, в качестве средства рефакторинга, но старайтесь по возможности исключить необходимость генерации кода. Как правило, генерация кода показывает, что в вашей среде чего-то не хватает - недостаток языка, ограничение встроенного инструмента и т. Д.

Тем временем научитесь хорошо использовать доступный API, особенно в отношении производительности и надежности, а затем включите эти уроки в свой собственный абстрактный уровень доступа к данным. Например, научитесь правильно использовать параметры в SQL, а не встраивать литеральные значения в строки SQL.

Наконец, имейте в виду, что любое приложение / система, которая станет успешной, будет расти с проблемами производительности. Устранение проблем с производительностью зависит скорее от их разработки, а не от «подстройки» чего-либо в реализации. Эта проектная работа повлияет на базу данных и приложение, которые должны меняться синхронно. Поэтому старайтесь легко (гибко) вносить такие изменения, а не пытаться избежать изменения самого приложения. Частично это в конечном итоге означает возможность развертывания изменений без простоев. Это не сложно сделать, если вы не «замышляете» от этого.

17
12.12.2008 22:59:57
«Строго применять принцип СУХОЙ (не повторяй себя)» также подразумевает не переписывать одну и ту же сантехнику в каждом приложении. Ваша привязанность к реализации уровня данных повлияет на каждое решение и в конечном итоге задушит вас скучными техническими деталями.
Bryan Watts 12.12.2008 23:36:18
Я согласен с тобой на 100%. Создание собственного уровня доступа к данным с использованием чистого ADO.NET с полным контролем над SQL и объектами - это путь. Вот это инструмент , который может вас заинтересовать .. forums.orasissoftware.com/...
Ahmad 13.12.2008 02:24:38
Это похоже на другой инструмент ORM Ахмад. Обычно это сводится к DataReaders и т. Д. Под прикрытием ... ORM почти избавляет вас от написания одного и того же кода вручную снова и снова. С другой стороны, мы написали наш собственный инструмент ORM, поэтому я признаю, что мне нравится контролировать утечки в моих абстракциях.
Brian MacKay 13.12.2008 18:20:43
Это не другой инструмент ORM! Это генератор кода, который создает ваш DAL для вас в соответствии с вашими бизнес-требованиями относительно ваших собственных бизнес-объектов. Вы можете сохранить ваш сгенерированный код, и код не будет зависеть от каких-либо проприетарных библиотек. Ни один ORM не может сделать это.
Ahmad 15.12.2008 15:51:13
@Ahmad: с вашего URL: «Orasis Mapping Studio - это инструмент для реляционного сопоставления объектов и генератора кода ...», поэтому они говорят, что это инструмент ORM. У него даже есть своя IDE?!? Хлоп.
Rob Williams 15.12.2008 20:47:57

Нет, не все

Вот большой слон номер один в комнате с большинством инструментов ORM (особенно LINQ to SQL):

Вам гарантировано, что ЛЮБЫЕ изменения, связанные с данными, потребуют полного повторного развертывания вашего приложения.

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

5
12.12.2008 16:24:03
Это не совсем правильно. Большинство ORM (включая LINQ) позволяют запрашивать хранимые процедуры, а не напрямую к таблицам вашей базы данных.
Brandon Wood 12.12.2008 16:27:38
Linq to Sql может использовать процы, если хотите: weblogs.asp.net/scottgu/archive/2007/08/16/…
Corbin March 12.12.2008 16:29:12
Я просто хотел бы сказать, что я думаю, что идея о том, что вы можете волшебным образом изменить базу данных, не затрагивая приложение, в большинстве случаев является бессмысленной ерундой. Приложения настолько сильно управляются данными, что, по моему опыту, даже незначительное изменение базы данных в большинстве случаев потребует изменения кода.
Sam Schutte 12.12.2008 21:25:11
@DotNetDaddy: Давайте посмотрим, у вас есть простой запрос выбора, который вызывает тупик в большой часто используемой таблице. Как вы это исправите? С S'procs вы просто исправляете запрос. С помощью ORM вы исправляете запрос и повторно развертываете все приложение.
NotMe 12.12.2008 21:28:00
@ Ахмад: Когда у вас есть несколько проектов, которые зависят от одной базы данных, очень важно, чтобы вы получили SQL-код OUT приложений. Представьте, что вам нужно внести небольшие изменения в базу данных. С вашим методом вы ДОЛЖНЫ повторно развернуть ВСЕ приложения. С моей, вы не можете ничего перераспределить.
NotMe 15.12.2008 20:52:26

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

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

6
12.12.2008 16:27:46
Из любопытства - как вы тестируете свой код LLBLGen? Мы использовали его в течение многих лет, но на самом деле не поставили уровень модульного тестирования, который нам нужен. Спасибо!
Beep beep 14.06.2009 03:21:45
+1. «Если ваша схема базы данных относительно близка к тому, как должны быть ваши бизнес-объекты, ORM являются лучшими».
user166390 21.12.2010 20:53:46

Я огромный сторонник ORM. Генерация кода с помощью ORM экономит мой магазин на 20-30% в большинстве наших проектов.

И мы занимаемся разработкой контрактов, так что это большая победа.

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

Кроме того, вы все еще можете полагаться на традиционные sprocs и даже представления, когда это уместно ... Мы не догматически 100% ORM, это точно.

12
12.12.2008 16:41:28
В чем проблема с наличием запросов в коде приложения, а не в хранимых процессах? Лучше иметь их в коде приложения и проверять во время компиляции ..... в противном случае вас ждут сюрпризы во время выполнения. Это большое преимущество ORM, особенно Linq To SQL.
Ahmad 14.12.2008 16:40:59
Существует целый огромный спор об этом. Или был. Может быть, мы прошли это. По сути, вы не хотите, чтобы объединенный SQL был в вашем коде, это считается злом, но это именно то, что делают ORM! Они либо строят конкатенированные параметризованные запросы, либо связывают их с sprocs-компонентами.
Brian MacKay 14.12.2008 17:43:54
Теперь я придерживаюсь противоречивого мнения о том, что, может быть, можно просто использовать sprocs для задач, в которых ORM плохо работают (что-либо, что может вызвать много циклов, дорогостоящих пакетных транзакций и т. Д.), Но многие администраторы баз данных не согласны. Некоторым людям нужна безопасность на уровне sproc и т. Д. Я это признаю.
Brian MacKay 14.12.2008 17:46:59
Если вы много занимаетесь разработкой контрактов и хотите сэкономить деньги, контролировать качество кода и измерять прогресс в DAL, вы можете обратиться к этой статье. forums.orasissoftware.com/...
Ahmad 15.12.2008 16:19:44
«Измерение прогресса DAL». Что ты этим имеешь ввиду?
Mauricio Scheffer 19.12.2008 00:36:48

Я очень внимательно следил за Fluent-NHibernate, так как он обладает одним из самых больших потенциалов, которые я когда-либо видел в проекте.

0
12.12.2008 16:31:29

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

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

Я переключился на LINQ и никогда не оглядывался назад. DBLinq отлично подходит для работы с базами данных, отличными от MSSQL. Я использовал его с моим SQL, и это здорово.

0
12.12.2008 16:35:55
ORMs не ускоряют вещи в моем опыте. Они фактически запрещают вам использовать настройку / оптимизацию запросов для повышения производительности. Они могут повысить скорость разработки, но по моему опыту они всегда работают медленнее или равны традиционным подходам.
Ahmad 12.12.2008 17:08:33
Большинство ORM поддерживают использование хранимых процедур. Для деталей, критичных к производительности, используйте правильный инструмент.
Min 12.12.2008 18:54:27

пока нет, все еще скептически; Как и большинство продуктов Microsoft, я жду SP2 или полтора года, прежде чем доверять им в среде producton.

и обратите внимание, что почти каждая новая вещь, представленная кем-то, а не только Microsoft, провозглашается «легкой, быстрой и простой» - возьмите ее с собой. Они не так громко рекламируют проблемы / проблемы, как преимущества / возможности! Вот почему мы ждем, чтобы ранние последователи обнаружили их.

Это не должно унижать ORM или LINQ или что-то подобное; Я оставляю за собой

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

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

0
12.12.2008 16:39:59
Да, что мы действительно делаем в своей работе - мы берем наш собственный внутренний инструмент ORM (который на самом деле довольно приличный), а затем используем CodeSmith для генерации BusinessObjects. Работает отлично. Я оцениваю альтернативы, такие как Linq2Sql, Subsonic и т. Д. Но это большой вызов.
Brian MacKay 12.12.2008 16:46:39
Linq2sql лучше, чем любой традиционный ORM ... фактически любой ORM, который имеет поддержку Linq, лучше, чем традиционный.
Pop Catalin 12.12.2008 16:56:43
Если codemith генерирует код на основе ваших таблиц, разве вы все еще не связаны с вашей схемой данных? Я бы предпочел решение, которое отделяет мои объекты от схемы базы данных для большей гибкости в архитектуре.
Ahmad 12.12.2008 17:13:54
Ахмад - в CodeSmith вы можете писать шаблоны, которые будут генерировать все, что вы хотите, основываясь на том, что вы хотите - это .Net. В нашем инструменте ORM он в конечном итоге работает с документом XML, который изначально основан на базе данных. Вы можете делать все что угодно там. Инструменты следующего поколения делают еще больше.
Brian MacKay 12.12.2008 18:10:09
@steven: ORM не новы в .net. Я использую NHibernate в течение трех лет, сейчас это очень стабильный продукт.
Mauricio Scheffer 19.12.2008 00:49:02

Я также большой поклонник, использующий EF и Linq-to-SQL. Мои причины:

Поскольку LINQ компилируется и печатает безопасно, вы не получите проблем с опечатками в «строковом» SQL. Я не знаю, сколько часов я провел в своей жизни, отслеживая ошибку в SP или другом SQL, где «галочка» или какое-то другое ключевое слово было в неправильном месте.

Вышеуказанные и другие факторы ускоряют развитие.

Хотя по сравнению с методами «ближе к металлу» запросов к базе данных, безусловно, есть издержки, никто из нас вообще не использовал бы .NET или даже C ++, если бы производительность была нашей задачей № 1. Для большинства приложений я смог получить отличную производительность от Linq-To-SQL, даже без использования хранимого метода proc (скомпилированные запросы на клиенте - мой обычный подход).

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

1
12.12.2008 16:40:38
что хорошего в безопасности типов, если вы не можете перемещать данные (то есть анонимные типы, которые дают строгую типизацию, не могут быть перемещены из локальной функции)
alchemical 2.07.2009 19:36:23
Анонимные типы - это не то, что дает строгую типизацию - строгая типизация происходит от классов, созданных для объектов базы данных. На них можно возвращаться и ссылаться за пределы фактического вызова базы данных, хотя я обычно считаю, что лучше использовать POCO вместо этого, просто для лучшего разделения.
Sam Schutte 7.07.2009 04:59:34
+1 Тем не менее, хороший инструмент БД сможет анализировать SP (новые или существующие) и сообщать вам, если они содержат какие-либо синтаксические ошибки или потенциальные несоответствия. Я уверен, что есть аналогичные инструменты для других подходов "обертка SQL". LINQ / EF просто форсируют это из-за того, как они управляют (но ряд динамических ORM - например, Rails - не предлагают эту «статическую» проверку, даже если они генерировали допустимый синтаксис SQL).
user166390 22.12.2010 01:54:29

Я предполагаю, что я имел в виду, что такое инновация, которую предоставляют ORM по сравнению с построением DAL с использованием традиционных ADO.NET, SQL и отображением их в объекты в коде?

Вот три главных особенности моего DAL, и я сравниваю их с ORM, чтобы увидеть преимущества:

  1. Вы все еще должны иметь запрос в ORM = SQL (SQL намного более мощный)

  2. Код отображения перемещается в конфигурацию, но все еще не устранен, просто переходит от одной парадигмы к другой

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

Я что-то пропустил?

1
12.12.2008 17:05:49
Ахмад - это в основном и есть ORM. Они предназначены для того, чтобы быть очень гибкими объектами для ввода и вывода данных из базы данных ... Более гибкими, чем CRUD. А с генерацией кода вам не нужно делать это вручную. Вы можете построить 200 объектов мгновенно. Посмотрите в CodeSmith например.
Brian MacKay 12.12.2008 17:32:46
И есть коллекции, и т.д., так что вы можете сделать привязку данных. Это просто более простой способ работы с данными, и он работает во многих сценариях.
Brian MacKay 12.12.2008 17:33:17
О, и это проще сделать запрос. Вам не нужно писать целый спрок каждый раз, когда вам нужно получить новые данные. Это огромная экономия времени.
Brian MacKay 12.12.2008 17:34:23
@Ahmad: с HQL NHIbernate, например, большинство запросов на самом деле меньше, чем их эквивалент SQL. См. Hibernate.org/hib_docs/nhibernate/1.2/reference/en/html/…
Mauricio Scheffer 14.12.2008 00:25:54
HQL может быть меньше, но SQL, который генерируется под ним, может быть намного больше и медленнее, чем если бы вы написали SQL. Итак, что вы покупаете у читабельности. В конце дня запрос должен дать правильные результаты и быстро. Оба из которых HQL-запрос не может гарантировать.
Ahmad 14.12.2008 16:36:22

Если codemith генерирует код на основе ваших таблиц, разве вы все еще не связаны с вашей схемой данных? Я бы предпочел решение, которое отделяет мои объекты от схемы базы данных для большей гибкости в архитектуре

Это из одного из ваших комментариев - это правда, CodeSmith тесно связывает вас с вашими столами.

NHibernate, с другой стороны, имеет множество функций, которые могут помочь с этим: у вас есть Компоненты, так что в коде вы можете иметь: Персона с свойством Address, где Address - это отдельный класс.

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

0
12.12.2008 17:36:21
Думаю, я не согласен с тем, что CodeSmith тесно связывает вас с таблицами. Вы можете написать шаблоны, чтобы генерировать все, что вы хотите. :) Мой инструмент ORM позволяет создавать все виды вещей.
Brian MacKay 12.12.2008 18:07:53

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

0
12.12.2008 17:44:46
Вам следует использовать генератор DAL, который может генерировать код для сопоставления SQL с объектами. Ibatis - это одно, а Orasis Mapping Studio - другое. Вы можете Google их.
Ahmad 12.12.2008 18:52:13

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

Так что нет.

2
12.12.2008 18:13:41
Правильный. Не должен ли уровень DAL все о производительности? Я видел сценарии, в которых ORM, такие как nHibernate, тратят минуты, чтобы открыть экран с интенсивным использованием данных. Когда мы просмотрели журнал SQL, он выполнил сотни запросов!
Ahmad 12.12.2008 20:50:04
«Я видел сценарии, в которых ORM требуется несколько минут nHibernate, чтобы открыть экран с интенсивным использованием данных», - я видел ту же ситуацию с SQL-серверами, запущенными вручную. Инструменты не виноваты в этом разработчик.
Owen 13.12.2008 14:02:30
Да, но в SQL вы можете улучшить производительность, настроив ваш SQL и все. В ORM у вас нет контроля над генерируемым SQL, поэтому вы обязаны. Единственный вариант, который у вас есть, это изменить отношения объектов и создать «легкие» объекты, которые портят вашу модель домена.
Ahmad 13.12.2008 15:48:26
@Ahmad: если вы используете NHibernate и сталкиваетесь с «сотнями запросов», вы, вероятно, нажимаете «выбрать N + 1», в Интернете есть множество статей по этому поводу. Любой инструмент может быть использован неправильно.
Mauricio Scheffer 14.12.2008 00:17:41

ORM хорошо подходит для людей, которые хорошо ладят с программным обеспечением, которое пишет программное обеспечение для них; но если вы одержимы контролем над тем, что происходит и почему, ORM может быть неоптимальным, особенно с оптимизацией базы данных. Любой уровень абстракции имеет свои издержки и выгоды; У ORM есть и то и другое, но баланс еще не правильный ИМХО. И ORM, в его нынешнем виде, по иронии судьбы добавляет уровень абстракции, который по-прежнему тесно связывает воедино классы и схемы без базы данных.

По моему опыту, это может помочь вам быстро собрать пробную версию, но может ввести требования к рефакторингу, с которыми вы, возможно, не знакомы (по крайней мере, пока).

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

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

4
12.12.2008 18:28:34
Вот хорошая дискуссия о том , как выбрать осуществление доступа к данным: forums.orasissoftware.com/...
Ahmad 12.12.2008 21:21:04
Вот еще одно, лучше IMO: ayende.com/Blog/archive/2006/05/12/… Соответствует ли Orasis всем этим функциям?
Mauricio Scheffer 19.12.2008 00:39:38
Orasis - это не ORM, это генератор кода DAL. Генератор кода, который генерирует исполняемый код для заполнения ваших объектов данными из запросов. Так что этот список не относится. Все эти функции не обязательны для реализации всеми DAL, некоторые из них являются функциями бизнес-уровня.
Ahmad 20.12.2008 16:02:20

На самом деле я работаю над написанием инструмента ORM в .NET в качестве побочного проекта, чтобы развлечь меня.

SQL мертв для меня. Я ненавижу писать это, особенно когда это где-то в моем коде. Написание вручную запросов выбора / вставки / обновления / удаления для каждого объекта - пустая трата времени IMO. И даже не начинайте работать с NULL ("где col_1 =?" Против "где col_1 равен нулю") при динамическом генерировании запросов. Инструменты ORM могут справиться с этим для меня.

Кроме того, имея 1 место, где SQL может генерироваться динамически, можно надеяться, что это будет означать устранение атак внедрения SQL.

С другой стороны, я использовал Hibernate и абсолютно ненавижу его. В реальном проекте мы сталкивались с ограничениями, невыполненными битами и ошибками каждые несколько недель.

Сохранение стороны БД логики запросов (обычно в виде представления или хранимой процедуры) также имеет преимущество в доступности для настройки администраторами баз данных. Это была постоянная битва на моей последней работе с использованием Hibernate. Администраторы базы данных: «предоставьте нам все возможные запросы, чтобы мы могли настроить» Devs: «ну, я не знаю, потому что Hibernate сгенерирует их на лету. Хотя я могу дать вам немного HQL и отображение XML!» АБД: «Не заставляй меня бить тебя по лицу!»

0
12.12.2008 18:53:52
Так что, если вам неудобно работать с NULL и писать простой SQL вручную, то это либо ORM, либо найти кого-то, кто этого не делает?
dkretz 12.12.2008 19:12:32
«дайте нам ВСЕ возможные запросы, чтобы мы могли их настроить»: это не способ оптимизации. Сначала найдите страницы / варианты использования, которые плохо работают, и проанализируйте их. Если его нельзя оптимизировать на уровне кода / ORM (т. Е. «Выбрать N + 1»), замените его вручную настроенным SQL-кодом администратора базы данных, проверьте на отсутствие индексов и т. Д.
Mauricio Scheffer 14.12.2008 01:18:14

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

В частности, с отражением .Net я не вижу необходимости в генерации кода для целей ORM.

0
12.12.2008 19:08:08
Под генерацией кода вы подразумеваете SQL, который генерируется такими вещами, как LINQ to SQL?
Richard Ev 12.12.2008 23:10:38
0
14.12.2008 18:30:54
Еще один об этом, который я люблю от Ayende: ayende.com/Blog/archive/2006/05/12/…
Mauricio Scheffer 14.12.2008 20:13:08

Это не повод для прыжка, это реакция на реальную проблему! Object Relational Mapping (ORM) существует уже давно, и это решает реальную проблему.

Оригинальные объектно-ориентированные (ОО) языки предназначались для моделирования реальных проблем с использованием компьютерного языка. Можно утверждать, что если вы действительно используете OO-язык для построения систем, вы будете имитировать реальную проблемную область, используя Domain Driven Design (DDD). Это логически ведет вас к модели разделения проблем, чтобы ваш DDD был чистым и понятным от всего беспорядка, связанного с сохранением данных и управлением приложениями.

Когда вы строите системы в соответствии с шаблоном DDD и используете реляционную базу данных для постоянного хранения, вам действительно нужен хороший ORM, или вы будете тратить слишком много времени на создание и поддержание неоправданной базы данных (каламбур).

ORM - старая проблема, которая была решена несколько лет назад с помощью таких продуктов, как Object Lens и Top Link. Object Lens представлял собой Smalltalk ORM, созданный ParkPlace в 90-х годах. Top Link был создан Object People для Smalltalk, затем преобразован для Java и в настоящее время используется Oracle. Топ Линк также существует с 90-х годов. Защитники DDD теперь начинают четко формулировать аргументы в пользу DDD и приобретают умственную долю. Поэтому ORM по необходимости становится мейнстримом, а Microsoft просто реагирует как обычно.

6
16.12.2008 05:33:07

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

Во-первых, новый Linq to SQL работает так же, как и хранимые процедуры и устройства чтения данных. Мы используем наборы данных везде, поэтому производительность будет улучшаться. Пока все хорошо для ORM.

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

В-третьих, сложно отлаживать хранимые процедуры. Они часто приводят к ошибочному поведению по ряду причин. Это не означает, что то же самое не могло быть результатом динамического sql, генерируемого ORM, но одна меньшая проблема - это одна меньшая проблема. Нет проблем с разрешениями (хотя в основном они решены в SQL 2005), больше нет многошаговой разработки. Написание запроса, тестирование запроса, развертывание запроса, привязка его к коду, тестирование кода, развертывание кода. Запрос является частью кода, и я считаю это хорошей вещью.

В-четвертых, вы все еще можете использовать хранимые процедуры. Запуск каких-либо отчетов, которые занимают много времени? Хранимые процедуры - лучшее решение. Почему? Планы выполнения запросов могут быть оптимизированы ядром базы данных. Я не буду притворяться, что понимаю всю работу базы данных, но я знаю, что существуют некоторые ограничения для оптимизации динамического SQL в настоящее время, и это компромисс, который мы делаем при переходе на ORM. Тем не менее, хранимые процедуры не исключаются при использовании решения ORM.

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

2
16.12.2008 05:52:19
Вот мои два цента после опыта работы над масштабным проектом ORM. theahmadblog.blogspot.com
Ahmad 16.12.2008 15:50:29
Какой ORM вы использовали Ахмад?
Ty. 19.12.2008 01:35:57

Нет, я сбросил ORM и переключился на болтовню и OODB: Gemstone. Лучший код, меньше кода, более быстрая разработка.

0
21.12.2010 20:46:39