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

Q>>А причем тут БД, а если нужно хранить данные просто в памяти, а для хранения скидывать их в файл через серелизацию, как тогда организовывать работу с данными?
G>При том, что без БД репозиторий имеет еще меньше смысла..
А при чем тут вообще какая-либо конкретная реализация? Списки, БД... почему вы не рассматриваете удаленный веб-сервис, например, в таком случае?
Задача любого архитектурного паттерна — фрагментация сложности. Паттерны DAL отделяют сложность бизнес-логики от сложности работы с хранилищем данных с помощью разного вида интерфейсов. Repository абстрагирует БД как коллекцию, TDG как объектный интерфейс к таблице, CQRS изолирует отдельные операции и т.д. Архитектурные паттерны — это интерфейсы, реализация которых может быть абсолютно любой. Используя их, вы говорите: клиенту должно быть всё равно, что за этим интерфейсом, пока они соблюдают контракт. Изменения в реализации, например, оптимизации производительности или журналирование, надежно скрыты за этим контрактом и не ломают клиентский код.
Реализация в виде хранилища в памяти тут просто удобная плюшка для ранних этапов разработки и юнит-тестов.