Генератор кода против ORM

Question

Я написал генератор кода, который генерирует POCO и репозитории для данной базы данных SQL Server / CE. Ничего особенного, только простые процедуры CRUD с использованием классического ADO.Net. Мой вопрос: почему я должен использовать ORM, такой как L2S / EF4, по сравнению с генератором нестандартного кода? Каждые 2 или 3 года Microsoft выпускает новую платформу / технологию доступа к данным, и я знаю немало разработчиков, которые не всегда могут быть в курсе новейших технологий, но каждый из них знает классическую ADO.Net, как изменить существующий код и как разработать новые функциональные возможности. Инструменты ORM приносят что-то, что является обязательным в наши дни, или я могу придерживаться классического ADO.Net?

Спасибо!

Answer 1

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

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

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

РЕДАКТИРОВАТЬ : еще два очка:

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

2) Пару лет назад я написал запись в блоге «Почему я не использую ORM», на которую я не буду ссылаться, потому что она была слишком подстрекательской. Через некоторое время я снова попытался уловить смысл того, почему можно объективно взглянуть на ORM и не видеть никакой ценности, не подрывая его, и эта ссылка: http://database -programmer.blogspot.com / 2010/12 /historical-perspective-of-orm-and.html

Answer 2

Зависит; Вам нравится делать бесполезную занятость с базой данных, или вы предпочитаете, чтобы все это генерировалось?

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

На самом деле, это вопрос выбора того, как вы хотите провести время. Если вы видите ценность в работе на уровне данных, по ряду причин, которые вы можете оправдать, когда сравниваете что-то вроде LLBLGen, то сделайте это. Но для меня это не так.

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

Answer 3

Одним из преимуществ ORM является проверка времени компиляции. Я буду использовать структуру сущностей в качестве примера, так как это то, что я использую в качестве ORM.

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

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

По сути, ORM будет обрабатывать все крайние случаи, которых обычно не имеет домашнее решение.

var q = from c in ctx.contact
        where c.contactId < 4
        select c.firstName, c.lastName;


foreach(var temp in q){
   string fullname = temp.firstName + " " + temp.LastName;
}

Answer 4

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

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

Нет администратора БД, больше нет усилий по локальной разработке против неуправляемыхудаленный экземпляр БД, больше нет нюансов кросс-СУБД, больше нет хранимых процедур, больше нет запросов с жестко закодированными ссылками, нет более сложных запросов на миграцию SQL.

Итак, в идеале ваш ORM должен:

• Автоматическое управление схемой БД для вас
• Обеспечение реализации на месте шаблона активной записи
• Действительно иметь возможность инкапсулировать всю бизнес-логику

Другие приятные сахара:

• Автоматическое управление миграцией данных (если вы ожидаете частых изменений онтологии, а не изменений)
• Поддержка создания / импорта осветителей

Имейте в виду, что вы можете начать любой проект с ORM, как сказал @Noon, но вы не можете начать никогдаy проект без него в наши дни.В идеале ORM идеально подходят для проектов, в которых вы хотите, чтобы разработчики находились под полным контролем, или чтобы они запускали частные локальные экземпляры БД.В любом случае, это огромный скачок от подхода задом наперед: сделать запрос в DBA, пить кофе, пока DB не обновится, надеюсь, что это произойдет в течение недели.

Answer 5

Для простого CRUD и, если объекты представляют таблицу, генераторы кода доставят вас прямо к вашей цели.ORM становятся все более интересными, если

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

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

Существует альтернатива между генератором кода и полноценным ORM: средства отображения данных (например, MyBatis)., ранее известный как iBatis).