Na pewno nie jesteś tym, który myli rzeczy. :-)
Myślę, że odpowiedź na to pytanie zależy od tego, jak bardzo chcesz być purystą.
Jeśli chcesz mieć ścisły punkt widzenia DDD, zaprowadzi cię to jedną ścieżką. Jeśli spojrzysz na repozytorium jako wzorzec, który pomógł nam ustandaryzować interfejs warstwy oddzielającej usługi od bazy danych, spowoduje to przejście do kolejnej.
Z mojej perspektywy repozytorium to tylko jasno określona warstwa dostępu do danych, czyli ustandaryzowany sposób implementacji Twojej warstwy dostępu do danych. Istnieją pewne różnice między różnymi implementacjami repozytoriów, ale koncepcja jest taka sama.
Niektórzy ludzie będą nakładać na repozytorium więcej ograniczeń DDD, podczas gdy inni będą używać repozytorium jako wygodnego pośrednika między bazą danych a warstwą usług. Repozytorium, takie jak DAL, izoluje warstwę usług od specyfiki dostępu do danych.
Jedną z kwestii implementacji, która wydaje się je odróżniać, jest to, że repozytorium jest często tworzone za pomocą metod, które wymagają specyfikacji. Repozytorium zwróci dane, które spełniają tę specyfikację. Większość tradycyjnych DAL, które widziałem, będzie miała większy zestaw metod, w których metoda będzie wymagała dowolnej liczby parametrów. Chociaż może to brzmieć jak mała różnica, jest to duży problem, gdy wchodzisz w sferę Linq i Expressions. Nasz domyślny interfejs repozytorium wygląda następująco:
public interface IRepository : IDisposable
{
T[] GetAll<T>();
T[] GetAll<T>(Expression<Func<T, bool>> filter);
T GetSingle<T>(Expression<Func<T, bool>> filter);
T GetSingle<T>(Expression<Func<T, bool>> filter, List<Expression<Func<T, object>>> subSelectors);
void Delete<T>(T entity);
void Add<T>(T entity);
int SaveChanges();
DbTransaction BeginTransaction();
}
Czy to jest DAL czy repozytorium? W tym przypadku chyba oba.
Kim