Здравствуйте, Baudolino, Вы писали:

B>Здравствуйте, gandjustas, Вы писали:

Q>>>А причем тут БД, а если нужно хранить данные просто в памяти, а для хранения скидывать их в файл через серелизацию, как тогда организовывать работу с данными?
G>>При том, что без БД репозиторий имеет еще меньше смысла..
B>А при чем тут вообще какая-либо конкретная реализация? Списки, БД... почему вы не рассматриваете удаленный веб-сервис, например, в таком случае?
Потому что с веб-сервисом, базой данных и списком в памяти работа ведется совершенно по-разному.
1) Список в памяти можно обойти весь оператором foreach
2) К веб-сервису можно сделать запрос с определенными параметрами
3) К базе можно сделать SQL запрос, а еще она поддерживает транзакции.

Как вы эти три принципиально разные операции спрячете за одним универсальным интерфейсом?

В C# кстати придумали такой универсальный интерфейс — linq запросы. Но свой linq провайдер мало кто пишет, пользуется готовыми.
Вот и ответ на вопрос почему паттерн Repository бесполезен в наше время.


B>Задача любого архитектурного паттерна — фрагментация сложности. Паттерны DAL отделяют сложность бизнес-логики от сложности работы с хранилищем данных с помощью разного вида интерфейсов.
Обычная функциональная декомпозиция тоже занимается фрагметацией сложности. Для этого не нужно создавать отдельные сущности и паттерны.
И вообще никто не говорит, что надо в батонклике вызывать SqlCommand. Нужно использовать функциональную декомпозицию.

B>Repository абстрагирует БД как коллекцию
Это первая и главная ошибка. Коллекцция объектов в памяти и таблица в БД обладают принципиально разными свойствами с точки зрения кода, даже если можно их свести к одному интерфейсу.


B>Архитектурные паттерны — это интерфейсы, реализация которых может быть абсолютно любой.
Не может, у них контракты разные. См выше.

B>Изменения в реализации, например, оптимизации производительности или журналирование, надежно скрыты за этим контрактом и не ломают клиентский код.
Для этого снова не нужен репозиторий как паттерн.

B>Реализация в виде хранилища в памяти тут просто удобная плюшка для ранних этапов разработки и юнит-тестов.
Само по себе добавление репозитория на ранних этапах — бесполезное усложнение кода. Можно банально обращаться к статическим спискам в памяти пока не появится необходимость сохранять данные.