Как использовать репозиторий и блок шаблонов работы с ADO.NET?

Я строю ASP.NET приложение MVC 5.

Я читал о шаблонах репозитория и единицы работы (UoW)здесь.

в этих примерах используется Entity Framework, которая добавляет высокий уровень абстракции.

Я использую ADO.NET и не эф. Я хочу знать:

  1. имеет ли репозиторий и шаблоны UoW какой-либо смысл с ADO.NET?
  2. как будут выглядеть мои репозитории и UoW с ADO.NET? Любой Образцы?
  3. могу ли я добавить отдельную библиотеку классов для репозитория или сделать ее частью DAL?
7
ado.net asp.net-mvc design-patterns repository-pattern unit-of-work

4 ответов

Я написал блоге который учит вас, как писать независимый от драйвера код и как реализовать шаблон Uow / Repository с помощью plain ADO.NET.

Это немного слишком долго, чтобы включить в этот ответ, но в основном IDbtransaction будет представлять вашу единицу работы (или содержаться в одном), и каждый репозиторий будет принимать транзакцию или UoW в своем конструкторе.

чтобы создать команду с помощью IDbTransaction

using (var cmd = transaction.Connection.CreateCommand())
{
    cmd.Transaction = transaction;

    //do a CRUD operation here.
}
5

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

однако, чтобы ответить на ваш вопрос, я нашел Фаулера PoEAA книга бесценна в изучении того, как написать свой собственный UoW, DataMappers и Репозитории, все основанные на ADO.Net - ... Это написано кем-то, кто, очевидно, сделал это по-настоящему, сделал все ошибки, а затем задокументировал их, чтобы вам не пришлось. Я не читал статью, которую вы связали, однако я часто опасаюсь использовать такие статьи, поскольку они демонстрируют только поверхностное рассмотрение таких шаблонов.

1
  1. блок шаблона работы более важен, когда вы говорите о стандарте ADO.NET потому что вы должны быть абсолютно уверены, что соединения, которые вы открываете, открыты только в течение необходимого периода времени, достигнутого путем обертывания соединений внутри using заявления.
  2. блок работы в ADO.NET будет выглядеть примерно так:

using (SqlConnection con = new SqlConnection(//connection string) { using (SqlCommand cmd = new SqlCommand(storedProcname, con)) { //... } }

если вы используете using заявления, чтобы охватить вашу единицу работы, вы можете быть уверял, что под капотом SqlConnection.Dispose() называет SqlConnection.Close() метод, и SqlCommand.Dispose() звонки SqlCommand.Close().

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

некоторое время назад я написал блоге почему этот самый учебник, который вы связали, вреден . tldr; репозиторий использует DAO, реализующий UoW, но репозиторий не должен быть частью UoW. Если вы не хотите усложнять свою кодовую базу / жизнь.

чтобы ответить на ваши вопросы:

  1. как только вы используете EF или любой другой ORM, UoW автоматически реализуется там. Если вы идете по пути micro-ORM (нет уважительной причины использовать ado.net непосредственно), UoW в основном транзакции БД. Репозиторий всегда должен иметь дело с объектами приложения,никогда с объектами ORM (persistence). Если объекты приложения используются в качестве объектов персистентности, возможно, у вас есть стандартное приложение CRUD, и вам не нужен шаблон репозитория. Для простых приложений используйте ORM напрямую (это экономит много времени).
  2. репозиторий использует реализацию UOW DAO в качестве детали реализации. Остальная часть приложения ничего не знает вне самого репозитория (интерфейса).
  3. интерфейс репозитория определяется, где он используется (обычно это уровень домена/бизнеса). Хранилище реализация является частью DAL. Обратите внимание, что вы должны использовать репозитории только для изменения модели (создание/обновление/удаление). Для запросов гораздо проще и ремонтопригоднее иметь услуги запрос (объекты) обработка конкретных случаев использования и работа с БД напрямую.

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

1