Генераторы кода или ORM?

Question

Что вы предлагаете для слоя доступа к данным? Использование ORM, таких как Entity Framework и Hibernate OR, и генераторов кода, таких как Subsonic, .netTiers, T4 и т. Д .?

Answer 1

Для меня это не сложно, вы генерируете код.

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

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

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

Мне это кажется очевидным. Если ваше приложение управляется данными, то, конечно же, ваш код тоже должен управляться данными? Тем не менее, сказать, что это очень спорно.

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

Там действительно нет способа решить эту проблему. Базы данных работают с наборами данных. ООП сосредоточиться на экземпляров классов. Попытка жениться на двоих всегда заканчивается разводом.

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

Answer 2

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

В какой-то момент, надеюсь, вскоре после изучения Строк Соединений, SqlCommands, DataAdapters и всего этого, мы заметим, что:

1. Такой код некрасив
2. Очень скучно писать
3. Очень легко что-то пропустить, если вы делаете это вручную
4. Это должно повторяться каждый раз, когда вы хотите получить доступ к базе данных

Итак, проблема, которую нужно решить, это «как сделать то же самое много раз быстро»?

Я говорю нет.

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

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

Мне нравится делать вещи один раз, не много раз, независимо от того, как быстро я могу их делать.

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

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

Answer 3

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

Однако эта система начала выходить из строя через пять или шесть лет из-за увеличения размера и сложности приложения (5 или 6 веб-сайтов, несколько веб-сервисов, множество компонентов COM +, устаревший код и .net, 8+ баз данных с 800+ таблицы 4000+ процедур). Никто не знал, что что-то было, и размножение разгорелось.

Есть и другие способы облегчить обслуживание, кроме ООП; однако, если у вас очень сложный домен, то модель с расширенным доменом идеальна для IMHO, поскольку она позволяет выражать бизнес-правила в красивых инкапсулированных компонентах.

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

Я рекомендую использовать следующее: ORM или ручной рулон облегченного DAL. В настоящее время я перевожу проект на nHibernate с моего DAL, и у меня большой успех; Тем не менее, мне нравится иметь возможность использовать любой из этих вариантов. Кроме того, если вы правильно отделите свои задачи (доступ к данным из бизнес-уровня от презентации), у вас может быть один сервисный уровень, который может взаимодействовать с Dao (объектом доступа к данным), который для одного объекта является ORM, а для другого выполняется вручную. Мне нравится эта гибкость, поскольку она позволяет применять лучший инструмент для работы.

Мне нравится nHibernate вместо DAL, свернутого вручную, потому что, хотя мой DAL абстрагирует большую часть кода ADO.Net, вам все равно нужно написать код, который переводит считыватель данных в объект или объект и создает параметры.

Answer 4

Ненавижу это говорить, но это зависит. Если вы найдете инструмент ORM, который соответствует вашим потребностям, сделайте это. Мы разрабатывали нашу собственную систему небольшими шагами при разработке приложения. Мы используем C ++ и в любом случае не так много инструментов. В результате мы получили XML-описание базы данных, после чего были сгенерированы сценарий генерации SQL, базовый объектный уровень и метаданные.

Сделайте свою домашнюю работу и оцените эти инструменты, и вы найдете подходящую для ваших нужд.

Answer 5

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