Metody repozytorium a Rozszerzanie IQueryable

Myślałem o tym dużo ostatnio, po rozpoczęciu mojej obecnej pracy. Jestem przyzwyczajony do repozytoriów, idą pełną ścieżką IQueryable używając tylko repozytoriów bare bones, jak sugerujesz.

Czuję, że wzorzec repo jest dźwiękowy i wykonuje półefektywną pracę w opisywaniu, w jaki sposób chcesz pracować z danymi w domenie aplikacji. Jednak problem, który opisujesz, zdecydowanie występuje. Robi się bałagan, szybko, poza prostą aplikacją.

Czy są jakieś sposoby na zastanów się, dlaczego prosisz o dane na tak wiele sposobów? Jeśli nie, naprawdę uważam, że podejście hybrydowe jest najlepszym sposobem. Twórz metody repo dla rzeczy, które używasz ponownie. Rzeczy, które mają sens. Suche i takie tam. Ale te jednorazowe? Dlaczego nie skorzystać z IQueryable i seksownych rzeczy, które możesz z nim zrobić? To głupie, jak powiedziałeś, stworzyć metodę do tego, ale to nie znaczy, że nie potrzebujesz danych. Suchy nie ma zastosowania, prawda?

It would take dyscyplina, aby to zrobić dobrze, ale naprawdę uważam, że to właściwa droga.

Zdaję sobie sprawę, że to stare, ale ostatnio zajmowałem się tym samym problemem i doszedłem do tego samego wniosku co Chad: przy odrobinie dyscypliny, hybryda metod rozszerzeń i metod repozytoriów wydaje się działać najlepiej.

Niektóre ogólne zasady, których przestrzegam w mojej aplikacji (Entity Framework):

Zamawianie zapytań

Jeśli metoda jest używana tylko do zamawiania, wolę pisać metody rozszerzeń, które działają na IQueryable<T> lub IOrderedQueryable<T> (aby wykorzystać bazową dostawca.) np.

public static IOrderedQueryable<TermRegistration> ThenByStudentName(
    this IOrderedQueryable<TermRegistration> query)
{
    return query
        .ThenBy(reg => reg.Student.FamilyName)
        .ThenBy(reg => reg.Student.GivenName);
}

TERAZ MOGĘ używać ThenByStudentName() w mojej klasie repozytorium.

Zapytania zwracające pojedyncze instancje

Jeśli metoda polega na zapytaniu prymitywnymi parametrami, zwykle wymaga ObjectContext i nie może być łatwo wykonana static. Te metody pozostawiam w moim repozytorium, np.

public Student GetById(int id)
{
    // Calls context.ObjectSet<T>().SingleOrDefault(predicate) 
    // on my generic EntityRepository<T> class 
    return SingleOrDefault(student => student.Active && student.Id == id);
}

Jeśli jednak metoda polega na zapytaniu EntityObject przy użyciu jej właściwości nawigacji , zwykle można ją wykonać static dość łatwo i zaimplementowane jako metoda rozszerzenia. np.

public static TermRegistration GetLatestRegistration(this Student student)
{
    return student.TermRegistrations.AsQueryable()
        .OrderByTerm()
        .FirstOrDefault();
}

Teraz mogę wygodnie pisać someStudent.GetLatestRegistration() bez potrzeby użycia instancji repozytorium w bieżącym zakresie.

Zapytania zwracające zbiory

Jeśli metoda zwróci jakieś IEnumerable, ICollection lub IList, wtedy lubię go static, jeśli to możliwe, i pozostawić go w repozytorium , nawet jeśli używa właściwości nawigacji. np.

public static IList<TermRegistration> GetByTerm(Term term, bool ordered)
{
    var termReg = term.TermRegistrations;
    return (ordered)
        ? termReg.AsQueryable().OrderByStudentName().ToList()
        : termReg.ToList();
}

To dlatego, że moje GetAll() metody już działa w repozytorium i pomaga uniknąć bałaganu metod rozszerzeń.

Innym powodem, dla którego Nie zaimplementowano tych "getterów kolekcji" jako metod rozszerzeń, jest to, że wymagają one bardziej szczegółowego nazewnictwa, aby miało znaczenie, ponieważ Typ zwracania nie jest sugerowany. Na przykład, ostatnim przykładem będzie GetTermRegistrationsByTerm(this Term term).

Mam nadzieję, że to pomoże!

Sześć lat później jestem pewien, że @ Alex rozwiązał swój problem, ale po przeczytaniu zaakceptowanej odpowiedzi chciałem dodać moje dwa grosze.

Ogólny cel rozszerzenia IQueryable kolekcji w repozytorium w celu zapewnienia elastyczności i umożliwienia konsumentom dostosowywania wyszukiwania danych. To, co Alex już zrobił, to dobra robota.

Podstawową rolą warstwy usług jest przestrzeganie zasady rozdzielenia obaw i logiki adresowej związane z funkcją biznesową.

W rzeczywistych aplikacjach, logika zapytań często nie wymaga rozszerzenia poza mechanikę pobierania dostarczaną przez samo repozytorium (np. zmiany wartości, konwersje typu).

Rozważmy dwa następujące scenariusze:

IQueryable<Vehicle> Vehicles { get; }

// raw data
public static IQueryable<Vehicle> OwnedBy(this IQueryable<Vehicle> query, int ownerId)
{
    return query.Where(v => v.OwnerId == ownerId);
}

// business purpose
public static IQueryable<Vehicle> UsedThisYear(this IQueryable<Vehicle> query)
{
    return query.Where(v => v.LastUsed.Year == DateTime.Now.Year);
}

Obie metody są prostymi rozszerzeniami zapytań, ale jakkolwiek subtelne, mają różne role. Pierwszy jest prostym filtrem, podczas gdy drugi oznacza potrzebę biznesową (np. konserwacja lub fakturowanie). W prostym aplikację można zaimplementować w repozytorium. W bardziej idealistycznym systemie {[2] } najlepiej nadaje się do warstwy usług (i może być nawet zaimplementowany jako normalna metoda instancji), gdzie może również lepiej ułatwić strategię CQRS oddzielania poleceń i zapytań .

Kluczowe kwestie to (a) główny cel Twojego repozytorium oraz (b) jak bardzo lubisz stosować się do filozofii CQR i DDD.