Re: ServiceLayer - rozwaĹźanie, best practice

On Wed, 22 Feb 2012 18:02:20 +0100, MarlonB wrote:

Mógłbyś napisać coś więcej w jaki sposób / ze względu na co rozdzielasz
funkcjonalność na Service i Repository?

Behavior i Composite Actions - Service
Data Access - Repository

Ale w uproszczeniu, wszystko można traktować jako Service. Zostajesz
wtedy przy "Data Services". Ale tak jak napisałem:

/Podział ideologiczno-nomenklaturyowy jest czysto syntetyczny/

Przykładowo w wersji #A z której korzystam, jest overkill bo
kontroler nigdy nie korzysta bezpośrednio z repository,
tylko z serwisów, które z kolei "importują" sobie repozytoria.
Dochodzi do sytuacji w ktĂłrej
  IUserService.Get(int id);
jest bezpośrednim forwardem do
  IUserRepository.Get(id);
Nie zauważyłem żadnego zysku z takiego rozwarstwienia, więc
zacząłem także importować repozytoria bezpośrednio do kontrolerów.

Wszystko jest umowne, wybiera się ścieżkę najsensowniejszą z Twojego
punktu widzenia.

Repository wykorzystuje między warsta dataAccess a businessLogic. Jak
rozumiem repository ma tylko operacje CRUD? Dlatego nie bardzo widzę
zastosowania repository w serviceLayer, jako Ĺźe potrzebuje konkretnych
akcji. Być może coś źle rozumiem...

Dobrze rozumiesz. Repository pattern to CRUD.

Ciekawi mnie bardzo opinia kogoś już doświadczonego, czyli co powinno
znaleźć się w serviceLayer? Jakie patterny? W serviceLayer korzystam z unity
do pozyskania konkretnej implementacji danego serwisu.

ServiceLocator.Resolve<T>() będzie prawdopodbnie w zupełności jedynym
wymaganym callem kontenera IoC, defacto, ewentualnie wystarczy
sforwardować podstawowe calle Unity.

Może jakieś ciekawe artykuły jak dobrze zaprojektować to wszystko?

Przyjrzyj się SharpArchitecture, nie jest doskonałe, ale tak do
poglądowego ogarnięcia jest całkiem niezłe. Ostatnim razem jak
widziałem #A, było nieźle, nie wiem w jakim dokładnie stanie
architekturalnym jest wersja aktualna.

--
Pozdrawiam,
Łukasz 'Maly' Ostrowski.      l3v.pl/