Dobrze zaprojektowane polecenia zapytań i / lub specyfikacje

Od jakiegoś czasu szukam dobrego rozwiązania problemów przedstawionych przez typowy wzorzec repozytorium (rosnąca lista metod specjalistycznych zapytań itp. Patrz:http://ayende.com/blog/3955/repository-is-the-new-singleton).

Bardzo podoba mi się pomysł użycia zapytań poleceń, w szczególności poprzez użycie wzorca specyfikacji. Jednak mój problem ze specyfikacją polega na tym, że odnosi się tylko do kryteriów prostych wyborów (zasadniczo klauzuli where) i nie dotyczy innych kwestii zapytań, takich jak łączenie, grupowanie, wybór podzbioru lub rzutowanie itp. zasadniczo wszystkie dodatkowe obręcze, przez które musi przejść wiele zapytań, aby uzyskać poprawny zestaw danych.

(uwaga: używam terminu „komenda”, tak jak w schemacie poleceń, nazywanym również obiektami zapytań. Nie mówię o komendzie, jak w przypadku rozdzielania komend / zapytań, gdzie istnieje rozróżnienie między zapytaniami i komendami (aktualizacja, usuwanie, wstawić))

Więc szukam alternatyw, które otaczają całe zapytanie, ale wciąż na tyle elastyczne, że nie tylko zamieniasz repozytoria spaghetti na eksplozję klas poleceń.

Użyłem na przykład Linqspecs i choć znajduję jakąś wartość w możliwości przypisywania znaczących nazw do kryteriów wyboru, to nie wystarczy. Być może szukam mieszanego rozwiązania, które łączy wiele podejść.

Szukam rozwiązań, które inni mogli opracować, aby rozwiązać ten problem lub rozwiązać inny problem, ale nadal spełniają te wymagania. W połączonym artykule Ayende sugeruje użycie kontekstu nHibernate bezpośrednio, ale uważam, że w znacznym stopniu komplikuje to warstwę biznesową, ponieważ teraz musi również zawierać informacje o zapytaniach.

Będę oferować nagrodę za to, gdy minie okres oczekiwania. Dlatego proszę, aby twoje rozwiązania były godne, z dobrymi objaśnieniami, a ja wybiorę najlepsze rozwiązanie i podniosę poprzeczkę.

UWAGA: Szukam czegoś, co jest oparte na ORM. Nie musi być jawnie EF lub nHibernate, ale są one najpowszechniejsze i pasują najlepiej. Jeśli można go łatwo dostosować do innych ORM, byłoby to dodatkowym bonusem. Kompatybilny z Linq byłby również miły.

AKTUALIZACJA: Jestem naprawdę zaskoczony, że nie ma tutaj wielu dobrych propozycji. Wygląda na to, że ludzie są albo całkowicie CQRS, albo są całkowicie w obozie repozytorium. Większość moich aplikacji nie jest wystarczająco skomplikowana, aby zagwarantować CQRS (coś, co większość adwokatów CQRS chętnie mówi, że nie powinieneś tego używać).

AKTUALIZACJA: Wydaje się, że jest tu trochę zamieszania. Nie szukam nowej technologii dostępu do danych, ale raczej dobrze zaprojektowany interfejs między biznesem a danymi.

W idealnej sytuacji szukam pewnego rodzaju skrzyżowania obiektów zapytań, wzorca specyfikacji i repozytorium. Jak już wspomniałem powyżej, wzorzec specyfikacji dotyczy tylko aspektu klauzuli where, a nie innych aspektów zapytania, takich jak złączenia, podselekcje itp. Repozytoria zajmują się całym zapytaniem, ale po pewnym czasie wymykają się spod kontroli . Obiekty zapytań zajmują się również całym zapytaniem, ale nie chcę po prostu zastępować repozytoriów eksplozjami obiektów zapytań.

questionAnswers(4)

yourAnswerToTheQuestion