ASP.NET MVC: Ile jest repozytoriów?

Question

Jestem w trakcie projektowania strony internetowej w ASP.NET MVC i jestem może trochę zdezorientowany co do dokładnej natury repozytorium.

Po przykładzie NerdDinner moja witryna powinna mieć jedno repozytorium, które obsługuje te elementy, które są im potrzebne. Jednak słyszałem również, że powinieneś mieć różne repositorys, które zajmują się określonych zestawów powiązanych podmiotów ....?

W przypadku mojej witryny będzie wiele podmiotów (około 15 tabel), ale większość z nich jest powiązana. Czy dobrze jest mieć jedno repozytorium, które zawiera wszystkie metody, które będę potrzebować do ciągnięcia/aktualizowania/usuwania itp. Czy powinienem je podzielić?

Answer 1

utworzyć repozytorium dla każdego obiektu danych.

Na przykład prosta baza danych biblioteka może zawierać następujące repozytoria:

• AuthorRepository
• BookRepository
• PublisherRepository

Answer 2

Jeśli używasz ogólnego repozytorium, które akceptuje typy, to nie widzę powodu, aby używać więcej niż jednego.

używamy interfejsu tak:

public interface IRepository 
{ 
    void Save<ENTITY>(ENTITY entity) 
     where ENTITY : Entity; 

    void Delete<ENTITY>(ENTITY entity) 
     where ENTITY : Entity; 

    ENTITY Load<ENTITY>(int id) 
     where ENTITY : Entity; 

    IQueryable<ENTITY> Query<ENTITY>() 
     where ENTITY : Entity; 

    IList<ENTITY> GetAll<ENTITY>() 
     where ENTITY : Entity; 

    IQueryable<ENTITY> Query<ENTITY>(IDomainQuery<ENTITY> whereQuery) 
     where ENTITY : Entity; 

    ENTITY Get<ENTITY>(int id) where ENTITY : Entity; 

    IList<ENTITY> GetObjectsForIds<ENTITY>(string ids) where ENTITY : Entity; 

    void Flush(); 
} 

następnie wykorzystać w kodzie tak:

var returnedObjects = repository.GetAll<ObjectClass>(); 
var singleObject = repository.Get<ObjectClass>(id); 

Answer 3

myślę, być może słownictwa, co jest repozytorium może być mylące ciebie. Dla mnie repozytorium to magazyn danych (np. MS SQL Database), w którym przechowywane są twoje dane.
Po Repository Pattern zalecam utworzenie jednego repozytorium dla każdego magazynu danych. Większość moich projektów używam MS SQL, więc tworzę repozytorium dla tego DB (lubię używać Subsonic dla mojego DAL/ORM i implementuje wzór Repositry i wzór ActiveRecord), a następnie tworzę Fabryki dla każdej tabeli. To pozwala mi podsumować subsoniczne klasy ActiveREcord i daje mi abstrakcję.

Nadzieja ów pomocny, może ...

Answer 4

używam rodzajowe repozytorium, które jest dużo dla wielu podmioty.

Dla bardziej skomplikowanego, po prostu rozszerzam o to, co jest potrzebne. Najlepsze z obu światów.

Answer 5

W projektowaniu opartym na domenie obowiązuje zasada, że ​​repozytoria są przypisane do agregatu głównego. Możesz przeczytać więcej na ten temat here.

Im więcej czytam, tym bardziej myślę, że NerdDinner jest zbyt często postrzegane jako zbiór dobrych praktyk, podczas gdy nie jest to absolutnie (patrz here do dyskusji, zwłaszcza NerdDinner repozytorium).Dlatego ludzie często winę inne przykłady MS jak Oxite (i here:

Deweloperzy zbiegną się do niego, pochwała to i ślepo akceptować go jako ewangelii ponieważ pochodzi od Microsoftu (to już na dobrej drodze). Niestety, każdy deweloper, który przyjmuje jego ducha będzie być pozostawiony z unmaintainble, nietestowalna i nieczytelny bałagan

).

Answer 6

Mam tendencję do korzystania z repozytorium na grupę powiązanych uprawnień. tj. orderrepository może mieć:

Zamówienie i OrderDetail.

i miałoby inny, powiedzmy, klient, CustomerProfile itp

To utrzymuje repozytorium klas schludny.

Davy

Answer 7

Queen3 ma rację, można śledzić grupującymi teorii root. Zasadniczo pogrupowałem moje repozytorium nie myśląc w Entities, ale w jaki sposób logicznie grupują się one w aplikacji, którą buduję.

Na przykład:

CustomersRepository 
OrdersRepository 
... 

W CustomerRepository chciałbym umieścić metody GetCustomers, GetCustomer, AddCustomer, DeleteCustomer, AddCustomerContact, DeleteCustomerContact.

W OrdersRepository chciałbym umieścić metody GetOrders, GetOrder, AddOrder, CancelOrder, CloneOrder, AddOrderDetail, DeleteOrderDetail i tak dalej.

Answer 8

Nie należy tworzyć repozytoriów dla każdej tabeli. Jak powiedziała królowa3, powinieneś stworzyć repozytorium na każdy zagregowany root. Podobnie, jeśli produkty mogą mieć kategorię, repozytorium kategorii powinno być zagnieżdżoną klasą produktów. Śledź relację logiki domeny niż obiekty domeny.