Особенности проектирования репозитория

Question

В настоящее время я нахожусь в процессе разработки / реализации шаблона репозитория в приложении .NET.После многих дней исследований я чувствую, что подхожу ближе, но на самом деле существует так много идей и мнений, что я надеялся узнать мнение некоторых людей о конструктивных соображениях, которые у них могли возникнуть, если вы уже внедрили один из них.Итак ...

Итак, основная проблема дизайна, с которой я сталкиваюсь, это ... Общие против определенных репозиториев?Об этом много всего, и я много думал об этом, и все еще не определился.Я буду реализовывать интерфейс IRepository и базовый класс Repository.Затем принимается решение: оставить реализацию репозитория таким образом или сделать класс Repository абстрактным классом и расширить его с помощью определенных репозиториев так:

public Repository<T> Repository : IRepository<T>
instantiated as: Repository<Customer> CustomerRepository = new Repository<Customer>

или

public CustomerRepository CustomerRepository : Repository<T>, ICustomerRepository
instantiated as: CustomerRepository CustomerRepository = new CustomerRepository()

Изначально ябыл определенно для конкретной реализации.Количество повторного использования кода и уменьшенное количество интерфейсов и классов с общим репозиторием - большой плюс, но я считаю, что контракт, который он определяет, просто слишком широк.Разрешение запрашивать у уровня доступа к данным практически любым способом внешних объектов может привести ко всем видам проблем с производительностью и оптимизацией (как может администратор БД узнать, какие запросы выполняются на БД, не прочесывая весь код ... возможно, вверхна уровне пользовательского интерфейса !!!).Это привело меня к конкретным репозиториям, которые могут наследоваться от абстрактного BaseRepository, чтобы воспользоваться преимуществами повторного использования кода, в то же время определяя узкий контракт, такой как методы, такие как GetCustomerByName ().

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

1) Ограничивает ли использование спецификаций свободу перехода к другому источнику данных?Шаблон спецификации довольно легко использовать в репозитории, если источник данных поддерживает LINQ.Таким образом, наш метод хранилища будет выглядеть примерно так:

IEnumerable<T> Query(ISpecification<T> specification);

Но что если мы захотим создать хранилище с использованием более старого поставщика ADO.Net 2.0.Не нужно ли теперь каким-либо образом преобразовывать запросы в SQL-запрос в хранилище ???Или же всю таблицу клиентов нужно будет прочитать в память, поэтому каждый отдельный клиент должен быть проверен, прежде чем совпадения могут быть возвращены в совокупность.Это будет проблемой для нас ... У нас есть клиент, использующий базу данных MySQL, которая поддерживает .NET 4.0, но также и другой клиент с устаревшей базой данных DB2, у которого есть только поставщик .NET 2.0.

2) икак в случаях, когда задачи CRUD для каждого объекта могут быть нестандартными.то есть.Может быть, клиент не может быть удален ... Может быть, создание какой-то другой сущности не соответствует обычному шаблону создания других сущностей?Как это можно сделать с помощью общего хранилища.Мне действительно нравится модернизированный дизайн универсального репозитория с шаблоном спецификации, но я вернусь к конкретным репозиториям, если это не будет поддерживаться.Извините, что это было так долго ... но было бы здорово услышать идеи людей по этому поводу?

Я также хотел бы реализовать Unit Of Work и DI, но я хочу завершить дизайн своего хранилища, прежде чем двигаться дальше.

Answer 1

Может быть, я ошибаюсь, но, глядя на ваше объяснение, я не вижу ничего конкретного для шаблона хранилища. Ваш пример покрыт простыми DAO Кроме того, если ваша единственная проблема - разные rdbm для разных клиентов, у вас должна быть возможность иметь два разных конфа для вашей библиотеки ORM (если вы ее используете)

Почему бы вам не пойти с простым простым DAO? Посмотрите здесь, например, http://www.springframework.net/doc-latest/reference/html/nh-quickstart.html (название 42.3.3)

PS: не позволяйте шаблонам управлять вами, вы - Дизайнер, а не они: -)

1010 * редактировать * Вот обсуждение SO о такой вещи Шаблон репозитория против DAL

Answer 2

Насколько я понимаю, шаблон репозитория действует как набор объектов в памяти, которые домен может добавлять и получать.Затем хранилище скрывает фактическое постоянство и специфический для данных код от домена.Затем домен может создавать запросы для отправки в хранилище для действий.Интерфейс определяет контракт, который домен имеет с репозиторием, и затем могут быть реализованы различные репозитории, чтобы скрыть модель персистентности.

Разве это не то, что представлено тем, о чем я говорил выше?Очевидно, что удаление возможности запрашивать хранилище с помощью методов Get отходит от определения хранилища того, что клиент может запрашивать хранилище, но я бы подумал, что общая концепция остается прежней.Даже ссылка, которую вы мне прислали, называет их DAO хранилищем ...

Полагаю, это следует из второй отправленной вами ссылки, где, похоже, много совпадений (и путаницы ???)о репозиториях и DAL и о том, являются ли они одним и тем же и где они расходятся.

Независимо от того, является ли моя реализация реальным хранилищем или просто DAL, использование спецификаций ограничит меня технологией сохранения данных, которая поддерживает LINQ?(Кроме того, если LINQ обладает немного различными возможностями в зависимости от того, является ли он LINQ2SQL или LINQ2. Как бы то ни было, это не приводит к утечке требований к доступу к данным из репозитория / DAL?охватить конкретные проблемы персистентности в хранилище, когда они относятся к конкретной сущности?