Как создать правильный слой базы данных?

Question

В настоящее время я использую множество классов ado.net (SqlConnection, SqlCommand, SqlDataAdapter и т. Д.) Для выполнения вызовов на наш sql-сервер. Это плохая идея? Я имею в виду, что это работает. Однако я вижу много статей, которые используют ORM, nHibernate, subsonic и т. Д. Для подключения к SQL. Почему они лучше? Я просто пытаюсь понять, зачем мне вообще это нужно менять?

Обновление:

Я проверил следующий урок по использованию nHibernate с хранимыми процедурами.

http://ayende.com/Blog/archive/2006/09/18/UsingNHibernateWithStoredProcedures.aspx

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

Answer 1

Нет ничего плохого в использовании базовых классов ADO.NET.

Возможно, вам просто придется сделать намного больше ручной работы, чем необходимо. Если вы, например, выберите своих 10 лучших клиентов из таблицы с помощью SqlCommand и SqlDataReader, и вам придется итерировать результаты, извлекать каждый отдельный элемент данных (например, номер клиента, имя клиента и т. д.), и вы имеете дело очень тесно со структурами базы данных, например строки и столбцы. Это хорошо для некоторых сценариев, но в других слишком много работы.

То, что дает ORM, - это большая часть этой "тяжелой работы", выполняемой для вас. Вы просто указываете это, чтобы получить список ваших 10 лучших клиентов - как объекты «Клиент». ORM отключится и получит данные (скорее всего, с помощью SqlCommand, SqlDataReader), а затем вытащит кусочки и кусочки и соберет для вас красивые, удобные в использовании объекты «Customer», которые намного проще в использовании, так как они то, с чем имеет дело ваш код - объекты Customer.

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

Марк

Answer 2

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

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

В целом, они фантастические для быстрой сборки!

Answer 3

Прежде всего, ORM, скорее всего, справятся с созданием SQL-запросов гораздо лучше, чем ваш обычный не-SQL специализированный Joe:)

Во-вторых, ORM - это отличный способ несколько «стандартизировать» ваши DAL, повышая гибкость в разных проектах.

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

Answer 4

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

Answer 5

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

Answer 6

Стоит учесть одну вещь: будет ли будущий «новый разработчик» более склонен знать или изучать хорошо документированный и широко принятый OR / M или ваш пользовательский уровень доступа к данным?

Первая вещь для меня - это время. Минуты с моим любимым OR / M, nHibernate против часов / дней, написание пользовательского слоя доступа к данным с использованием ADO.NET.

Я также предпочитаю OR / M, потому что поддерживать декларативные сопоставления XML гораздо проще, чем поддерживать потенциально тысячи строк императивного кода ... или, что еще хуже, тысячи строк кода доступа к данным C # поверх тысяч строк кода хранимой процедуры. В моем текущем проекте у меня есть 58 объектов, сопоставленных в 58 файлах сопоставления XML, каждый из которых содержит менее 50 строк. Я смущаюсь, когда думаю о написании / поддержании кода CRUD для 58 объектов в ADO.NET.

Я должен предупредить вас, чтобы прочитать документацию. Многие, осмелюсь сказать больше всего, люди, с которыми я работал, будут прыгать на инструменте, как мыши на сыре, но они никогда не будут читать документацию и изучать технологию. Я рекомендую прочитать документы ПЕРЕД переходом на новую технологию, такую ​​как nHibernate. Хорошая чашка чая и час или два трудных чтений заранее принесут дивиденды.

Answer 7

Вам не нужно менять. Если SqlConnection, SqlCommand и т. Д. Работают для вас, тогда это прекрасно.

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