public interface IClientRepository
{    
    Client GetById(Guid id);   
    Client GetByQuery(Query query);
    void Add(Client client);
    void Remove(Client client);
    void Update(Client client);    
        
    /*Inne specyficzne metody dla obiektu "Client".
      Może być to np. wyszukiwanie klientów po sumie zamówien,
      regionie pochodzenia, kupowanych towarach itp.
    */ 

}

public interface IRepository<T>
{
    T GetById(Guid id);   
    T GetByQuery(Query query);
    void Add(T item);
    void Remove(T item);
    void Update(T item);    
}

public interface IOrderRepository:IRepository<Order>
{
    Order[] GetOrdersByClientId(Guid idClient);
}

public class OrderRepository:IOrderRepository)
{
    private IDataContext m_DataContext=null;
    public OrdeRepository()
    {
       // inicjalizacja m_DataContext
    }
    public void Add(Order item)
    {
       m_DataContext.Add(item);
    }
    ...
}

OrderRepository orderRepository = new OrderRepository();
ProductRepository productRepository = new ProductRepository();
ClientRepository orderRepository = new ClientRepository();

17 thoughts on “Wzorzec repozytorium (repository pattern)”

1. a jaka jest roznica pomiedzy repositort a starym dobrym dao? jakbym nie znal tytulu art. to bym pomyslal ze opisywane jest dao…

2. Ja bym zaliczył repository to warstwy biznesowej zatem oprócz czystych operacji CRUD może zawierać jakąś logikę.
   DAO to czysty DAL.

3. Piszę sobie od paru lat hobbystycznie w c# i mój ostatni programik do zarządzania licencjami wygląda właśnie tak. Tak więc jednak coś w tych wzorcach jest skoro wielu niezależnie od siebie dochodzi do tego samego 🙂 Wpis jak najbardziej jasny i zrozumiały. Czekam na następne 🙂

4. @Piotr Zieliński
   Uściślając moim zdaniem do warstwy biznesowej powinien należeć jedynie interfejs repozytorium. Implementacja warstwę niżej.

5. Implementacja musi być również w BL. Powiedzmy, że mamy metodę zwracającą listę produktów, które powinny być przecenione – jest to czysta logika biznesowa więc nie może znajdować się w DAL.
   Fizyczny odczyt z bazy danych powinien oczywiście znajdować się w DAL. Dlatego w przedstawionej implementacji (tzn. zarysie) repozytorium posiada referencje do IDataContext. Zatem IDataContext wykonuje operacje CRUD (zapytania SQL itp). Repozytorium nie zawiera implementacji DAL a wykorzystuje jedynie gotową klasę do tego.

6. Uuu, coś tu jest nie tam. Implementacja w BLL? Poważny błąd, ponieważ związujesz BLL z konkretnym sposobem dostępu do danych, w tym przypadku z IDataContext (Linq2Sql). A jakbyś chciał zmienić to na NHibernate’a po paru tygodniach (co jest dość częste, gdy wpada się w ograniczenia linq2sql)? Trzeba by wszędzie w _warstwie biznesowej_ zmienić IDataContext na ISession. A to znaczy jedno: bad design.

   BLL powinien być tworzony jako osoby DLL BEZ ŻADNEJ referencji do bibliotek zewnętrznych. Wtedy ma się pewność, że jest to warstwa abstrakcyjna, niezależna od niczego poniżej (ani od DAL ani od warstwy prezentacji aka GUI). W tym miejscu mogę się powołać na rozdział 4 z “Applying Domain-Driven Design and Patterns”.
   Jeżeli umieścisz część implementacji Repository w BLL to musi to być kod, który bezpośrednio NIE odwołuje się do bazy, ani do żadnej DLL powiązanej z bazą.

   Oczywiście są “wyjątki”. Gdy np korzysta się z MS Entity Framework’a warstwa DAL praktycznie nie istnieje ponieważ EF udostępnia ci cały model. Opakowywanie tego w kolejną warstwę jest w małych do średnich projektów bezcelowe.

7. Jeszcze raz zaznaczam, że repozytorium musi być niezależne od źródła danych. Dlatego napisałem IDataContext a nie DataContext. IDataContext to interfejs dostępowy do bazy danych. A jego implementacja jest wstrzykiwana przy starcie aplikacji. W moich projektach IDataContext to własny interfejs dostępowy do bazy danych. Następnie w zależności od bazy danych piszę adaptery np. nHibernateAdapter.

8. Acha co do wspomnianej przez Ciebie referencji. To jakaś referencja przecież w końcu musi być (zawsze luźna).

9. A to ok, IDataContext to (przypadkowo) też nazwa interfejsu linq2sql…

10. Moim zdaniem, lepiej byłoby wykorzystać wzorzec stragegy w OrderRepository oraz użyć wstrzykiwania IDataContext przez konstruktor.

    BTW Gratuluje ciekawych postów.

11. Zwykle IDataContext pobieram przez UnityContainer a konfiguracje UC umieszczam w pliku konfiguracyjnym aplikacji.Z kolei przez konstruktor jest o tyle dobrze, że łatwiej podczas testów wstrzyknąć mocka…

12. Czemu nie iść krok dalej 🙂

    public class RepositoryFactory : IRepository, IRepository
    {
    IDataContext dataContext;

    public RepositoryFactory(IDataContext dataContext)
    {
    this.dataContext = dataContext;
    }

    …..
    public IList GetByExample(T example)
    {
    IEnumerable result = this.dataContext.GetByExample(example, typeof(T)).Cast();

    return result.ToList();
    }

    public void Add(T item)
    {
    this.dataContext.Add(item);
    }
    }

    Wykorzystanie:
    RepositoryFactory emplRep = new RepositoryFactory(context);

    IList employees = emplRep.GetByExample(e);

13. Pozjadało nawiasy kątowe… Zastąpię je [[ i ]]

    public class RepositoryFactory[[T]] : IRepository[[T]]
    {
    IDataContext dataContext;

    public RepositoryFactory(IDataContext dataContext)
    {
    this.dataContext = dataContext;
    }

    …..
    public IList[[T]] GetByExample(T example)
    {
    IEnumerable[[T]] result = this.dataContext.GetByExample(example, typeof(T)).Cast();

    return result.ToList[[T]]();
    }

    public void Add(T item)
    {
    this.dataContext.Add(item);
    }
    }

    RepositoryFactory[[Employee]] emplRep = new RepositoryFactory[[Employee]](context);

    IList employees[[Employee]] = emplRep.GetByExample(e);

14. Pingback: [vebshop] Implementacja „Repository Pattern” – część pierwsza « Grzegorz Wodniczak
15. Pingback: Filtrowanie danych – manisero
16. Pingback: Spojrzenie w DAL – manisero
17. Pingback: Repozytorium | langusblog