Wielokrotnego użytku kwerendy w strukturze podmiotu BEZ repozytorium. W jaki sposób?

Question

Pozwólcie mi powiedzieć, że doszedłem do wniosku (po wielu próbach), że Repozytorium & Jednostka Pracy przy użyciu Entity Framework jest po prostu źle, źle, źle i this says why całkiem dobrze.

Ale naprawdę nienawidzę tych osadzonych zapytań. Pytanie brzmi: gdzie mogę je umieścić, jeśli jestem przeciwny repozytorium itp.? (czyste odpowiedzi tylko proszę, przykłady bardzo doceniane).

Właśnie nuked dwa projekty zawierające moje repozytoria, jednostkę pracy i interfejsy z setek plików, ponieważ zwrot nigdzie nie był widoczny. Myślę, że wielu ludzi, włącznie z mną, po prostu skoczyło na to, co robią członkowie repozytorium, bo tak właśnie robili inni, ale z perspektywy czasu, myślę, że to naprawdę jazda do nikąd.

/wzdychać

Richarda

Answer 1

Gdzie można oczekiwać, aby je umieścić? Masz tylko kilka możliwości:

1. niech się gdzie one są i stosowanie metod niestandardowych rozszerzeń, query views, odwzorowanych widoki bazy danych lub niestandardowe defining queries zdefiniować wielokrotnego użytku części
2. Expose każdą kwerendę jako sposobu na jakiejś oddzielnej klasie. Metoda ta nie może wystawiać wartości IQueryable i nie może akceptować Expression, ponieważ parametr = cała logika zapytania musi być zawinięty w metodzie. Ale to sprawi, że twoja klasa obejmująca podobne metody będzie podobna do repozytorium (jedyna, która może zostać wyśmiana lub sfałszowana). Ta implementacja jest zbliżona do implementacji używanej z procedurami przechowywanymi.
3. Zrobisz to samo, co w poprzedniej metodzie, ale zamiast umieszczać zapytania w oddzielnej klasie, wstawisz je jako metody statyczne bezpośrednio do encji. Jest to o wiele gorzej sprawdzalne, ponieważ metod statycznych nie można zastąpić szyderstwem (wymaga to bardziej złożonych ram testowania). Jest to część active record pattern, w której każda jednostka jest odpowiedzialna za jej ładowanie i zapisywanie w bazie danych.

Przykład metody niestandardowe rozszerzenia:

public static IQueryable<TEntity> GetByName(this IQueryalbe<TEntity> query, string name) 
    where TEntity : IEntityWithName 
{ 
    return query.Where(e => e.Name == name); 
} 

Przykład metod zwyczaj klasa narażając:

public class QueryProvider 
{ 
    public QueryProvider() {} 

    public IEnumerable<TEntity> GetByName(IYourContext context, string name) 
     where TEntity : IEntityWithName 
    { 
     return context.CreateObjectSet<TEntity>().Where(e => e.Name == name).ToList(); 
    } 
} 

Answer 2

Build Reusable, Testable Queries Part 1

To blogu pisałem o budowę wielokrotnego zapytań. Korzystanie z metod rozszerzeń pozwala tworzyć kompozycyjne zapytania.

użycie wzorca, takiego jak wzorzec specyfikacji, może pomóc w tworzeniu zapytań, które można ponownie wykorzystać lub zapisać (serializowane). Co więcej, jeśli masz system podwójnego wejścia, możesz wykonać to samo zapytanie przez dwie różne bazy danych.

Poniższy przykład nie używa EF, ale zastępuje IEnumerable przez kontekst EF i otrzymujesz to, czego szukasz. parametry są przekazywane za pośrednictwem konstruktora.

public class PartialMatchQuery : IModelQuery<string, IEnumerable<string>> 
{ 
    private readonly string partial; 

    public PartialMatchQuery(string partialString) 
    { 
     partial = partialString; 
    } 

    public IEnumerable<string> Execute(IEnumerable<string> model) 
    { 
     return model.Where(s => s.ToLower().Contains(partial)); 
    } 
}