🚀 go-pugleaf

Użytkownik "Łukasz 'Maly' Ostrowski" <maly@USUNnemo.pl> napisał w wiadomości 
news:1mt437iq9a6yz.1vti2z6dbuetk.dlg@40tude.net...
> 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.

Kapuje. U mnie będzie potrzebna właśnie taka warstwa, bo być może przed MVC 
będę miał jakiś web service.

> 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.


No to mam w takim razie pytanie. Czy serviceLayer ma mieć swoje własne view 
modele? Tzn czy oprócz zależności od domain modeli ma mieć jeszcze jakieś 
swoje modele, na które będę je mapował?
Bo stąd był mój pomysł z IDoctionary, bo coś musze zwracać. A co mam zwracać 
jesli nie domain modele? Jakiś ViewModel? Bo w MVC też mam ViewModele i nie 
bardzo wiem jak to pożenić.

dataaccessLayer, businessLayer, serviceLayer => te mają zależność od domain 
models.
UiWebLayer => ma zależność od serviceLayer i posiada własne ViewModele. Nie 
chciałbym, aby była zależność od domain models.

Co sprowadza się do tego, że serviceLayer musi zwracać swoje ViewModele, 
które będą mapowane na ViewModele z UiWebLayer :)

Cel jest taki aby niepotrzebnie nie mieszać i nie przepisywać ciągle z 
modelu na model, ale widzę, że trudno coś innego wymyśleć. Do mapowania 
używam Automappera, więc może nie będzie aż tyle roboty. Rzecz, której się 
boje, to nagły rozrozt aplikacji i możliwość pogubienia się i koszty w 
utrzymaniu skomplikowanego kodu. Teraz to wygląda niewinnie...

>> 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.
>

Sciągnąłem właśnie i sobie "na to pacze" :)

Dzięki za wskazówki.

Pozdro.

M.