Корпоративная библиотека Доступ к данным блокирует проектные решения

Question

Предыстория этого сообщения - коллеге не понравился тот факт, что мы стандартизировали блоки доступа к данным Enterprise Library, потому что

• Требовалось слишком много ссылок в каждом проекте, для которого требовался доступ к базе данных
• Нам не нужны были все предоставляемые функции
• Он считал, что DbCommand / SqlCommand должен храниться внутри объектов базы данных вместо того, чтобы позволить базе данных создавать sqlcommand и требовать от пользователя внешнего управления своим состоянием
• Ему не понравилось, что вы должны указывать тип при добавлении параметра, он думал, что перегрузки должны выводить тип для вас. * Не понравилось, что Enterprise Library была универсальной для всех баз данных, когда наша система в любом случае была только совместима с Sql Server

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

Почему Enterprise Library или другие уровни абстракции базы данных не обеспечивают перегрузки AddParameter для базовых типов?

Пример

   db.AddInParameter(dbCommand, 
     "EmployeeID", DbType.Int32, 1);

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

   db.AddInParameter(dbCommand, "EmployeeID", 1);

Некоторые причины, по которым я могу придумать ...

Если вы не укажете каждое сопоставление типов как перегрузку, может произойти следующая ситуация.

Допустим, у вас есть перегрузка для int, но не для char

char c = 'R'

db.AddInParameter(dbCommand, "Initial", c);

Компилятор разрешит перегрузку в int вместо char и выдаст ошибку, потому что хранимая процедура ожидает тип char.

Еще одним следствием является то, что если я хочу смоделировать класс Database, у меня теперь есть массивный интерфейс перегрузок, который мне нужно реализовать вместо одного.

Мой другой большой вопрос был ..

Почему блок доступа к данным требует, чтобы вы извлекли объект команды, а затем передали его обратно для последующих вызовов вместо простого управления его состоянием изнутри?

using (var cmd = db.GetStoredProcCommand("AddEmployee"))
{
      db.AddInParameter(cmd, "@Name", DbType.String, name);

вместо

using(var db = new Database())
{

      db.CreateStoredProcCommand("AddEmployee")

      db.AddInParameter("@Name", DbType.String, name);

Мне интересно посмотреть, что вы, ребята, думаете.

Спасибо

Answer 1

Первый вопрос:

Это всего лишь предположение, но я подозреваю, что это потому, что ADO.NET не предоставляет эту функциональность.

Второй вопрос:

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

Что касается хранения команды и ее параметров в объекте базы данных, объекты базы данных разработаны так, чтобы не содержать специфичное для команды состояние. Это позволяет их использовать повторно. Распространенным шаблоном является создание объекта Database один раз при запуске приложения и вызов его методов GetXXXCommand (), как требуется в течение срока службы приложения. Кроме того, многопоточные приложения (например, веб-сайты) могут безопасно создавать экземпляры DbCommands из одного объекта базы данных, даже при обслуживании множества одновременных запросов.

Если объект Database хранит неявную DbCommand, межпотоковое совместное использование экземпляров Database больше невозможно.

Наконец, даже в однопоточных приложениях вполне возможно создать несколько DbCommands или не иметь однозначного сопоставления между вызовами GetXXXCommand () и вызовами ExecuteXXX (). Например, вы можете выполнить их много раз, каждый раз с разными параметрами.

Answer 2

обратите внимание, что блоки доступа к данным корпоративной библиотеки - это не новая структура доступа к данным, а оболочка для обычного ADO.NET, которая автоматически выполняет многие функции, необходимые для крупных корпоративных приложений. Таким образом, он сохраняет только некоторые строки кода. Техника позади все еще проста ADO.NET. Пожалуйста, не могли бы вы дать больше информации о вашей проблеме? Насколько я понимаю, вам просто не нравится синтаксис API блоков доступа к данным Enterprise Library.