ORM (Linq, Будьте в спящем режиме …), действительно настолько полезный?

• Строгая типизация
• Нет необходимости писать DAL самостоятельно => экономия времени
• Нет необходимости писать код SQL самостоятельно => менее подвержен ошибкам

Раньше я использовал Hibernate для динамического создания довольно сложных запросов. Реализация логики, задействованной для создания соответствующего SQL, потребовала бы очень много времени по сравнению с логикой построения соответствующих критериев . Кроме того, Hibernate знал, как работать с различными базами данных, поэтому мне не нужно было вставлять эту логику в наш код. Нам, конечно, пришлось протестировать на разных базах данных, и мне нужно было написать расширение для соответствующей обработки «похожих» запросов, но затем оно без проблем работало с SQL Server, Oracle и HSqldb (для тестирования).

Также есть тот факт, что вам не нужно писать больше кода, что всегда приятно :) Я не могу сказать, что использовал LINQ to SQL в чем-то большом,

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

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

В настоящее время я начинаю с домена. Я моделирую его в UML, и большую часть времени я могу генерировать все из этой модели, включая схему базы данных. Здесь и там нужно немного доработать, но с моей текущей настройкой я выполняю 95% работы с доступом к данным в кратчайшие сроки. Сэкономленное время я могу использовать для точной настройки тех частей, которые нуждаются в настройке. Мне редко нужно писать какие-либо операторы SQL.

Это мои два цента. : -)

Переносимость между разными поставщиками баз данных.

Честно говоря - я новичок в ORM - вопрос: в чем заключается большое преимущество ORM по сравнению с написанием приличного DAL вручную?

Не все программисты хотят или даже могут писать "достойный ДАЛ". Те, кто не может или боится одной мысли об этом, считают LINQ или любой другой ORM благословением.

Я лично использую LINQ для управления коллекциями в коде из-за его выразительности. Он предлагает очень компактный и прозрачный способ выполнения некоторых общих задач с коллекциями непосредственно в коде.

LINQ перестанет быть полезным для вас, когда вы захотите создавать очень конкретные и оптимизированные запросы вручную. Тогда вы, вероятно, получите смесь запросов LINQ, смешанных с подключенными к нему настраиваемыми хранимыми процедурами. По этим соображениям Я отказался от LINQ to SQL в моем текущем проекте (поскольку у меня есть приличный (imho) уровень DAL). Но я уверен, что LINW отлично подойдет для простых сайтов, таких как, может быть, ваш блог (или SO, если на то пошло).

С LINQ / ORM также может учитываться отставание для сайтов с высоким трафиком (поскольку каждый входящий запрос будет придется компилировать заново). Хотя я должен признать, что не вижу проблем с производительностью на SO.

Вы также можете подумать об ожидании Entity Framework v2. Он должен быть более мощным, чем LINQ (и, надеюсь, не таким плохим, как v1 (по мнению некоторых)).

При использовании LINQ / ORM может также учитываться задержка для сайтов с высоким трафиком (поскольку каждый входящий запрос придется компилировать заново). Хотя я должен признать, что не вижу проблем с производительностью на SO.

Вы также можете подумать об ожидании Entity Framework v2. Он должен быть более мощным, чем LINQ (и, надеюсь, не таким плохим, как v1 (по мнению некоторых)).

При использовании LINQ / ORM может также учитываться задержка для сайтов с высоким трафиком (поскольку каждый входящий запрос придется компилировать заново). Хотя я должен признать, что не вижу проблем с производительностью на SO.

Вы также можете подумать об ожидании Entity Framework v2. Он должен быть более мощным, чем LINQ (и, надеюсь, не таким плохим, как v1 (по мнению некоторых)).

Прозрачное постоянство - изменения сохраняются (и передаются каскадом) без необходимости вызывать Save () . На первый взгляд это кажется кошмаром, но как только вы привыкнете работать с ним, а не против него, код вашего домена может почти полностью избавиться от проблем с постоянством. Я не знаю ни одного ORM, кроме Hibernate / NHibernate, который делает это, хотя могут быть некоторые ...

Я использовал Linq, он мне очень пригодился. Я экономлю ваше время на написание кода доступа к данным. Но для больших приложений вам нужно больше, чем DAL, для них вы можете легко расширить классы, созданные им. Поверьте, это действительно повышает вашу продуктивность.

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

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

• Hibernate и Linq проверены и протестированы многими, маловероятно, что вы сможете достичь такого качества без большого количества работы.

• Hibernate обращается ко многим функциям, которые потребуют от вас месяцев и лет для кодирования.