🚀 go-pugleaf

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.      http://l3v.pl/