Репозиторий дает одинаковый набор общих API, таких как :
- IEnumerable<TModel> GetModels();
- TModel GetModelByID(int modelId);
- void InsertModel(TModel model);
- void DeleteModel(int modelID);
- void UpdateModel(TModel model);
- void Save();
IEnumerable<TModel> GetModels(); иногда меняется на IQueryable<TModel>GetModels(), тем более в данном примере это более правильно (так как GetModels не имеет параметров, то материализация должна быть в самый последний момент).
Тоже и с сохранением. Нужно сохранить новые значения пользователя и записать в историю, получается нужно вызвать операции 2х репозитариев и как-то скоординировать сохранение, что бы откатить при сбое. Как решается эта проблема?
Это решается с помощью сервисов или Unit of Work, которые построены вокруг объединения репозиториев, связанных единой бизнес-логикой, единого экземпляра контекста, единой транзации где нужно и т.п.
Пример всего этого добра можно глянуть, к примеру, вот тут:
https://www.asp.net/mvc/overview/older-versions/ge...
Статейка старенькая, но для общего понимания пойдет. Но самая соль не в этом. Соль ситуации в том, что EF сам по себе UoW, а его DbSet-ы - это репозитории. Соответственно, вам нужны репозитории лишь в том случае, если вы желаете поддержку работы с несколькими, назовем это, бакэндами. В данном конкретном случае бакэендами могут быть:
- EF
- NHibernate
- Linq2db
- SqlClient/Npgsql/MySQL/etс (тут сложнее и потребуется поработать)
