🚀 go-pugleaf

Witam,

    Jestem w trakcie pisania warstwy ServiceLayer w moim projekcie. 
Pośredniczy ona między wartwą logiki biznesowej (businessLayer) a wartwą 
prezentacji, czyli jest ona fabryką różnych api, tak jak ja to rozumiem. Co 
mnie zastanawiało:
- Jak ma wyglądać takie api?
- Jakie typy danych ma zwracać?
- Jakie typy danych ma przyjmować na wejściu?

Warstwy businessLayer, dataAccessLayer, serviceLayer dzielą się w spólnie 
głupimi modelami danych - POCO, które odzwierciedlają jeden do jeden, to co 
jest w bazie danych. To znaczy, klasa User i jej właściwości odzwierciedlają 
tabelę User i jej kolumny w bazie danych.

Wprowadzenie serviceLayer ma m.in. za zadanie zerwanie zależności po między 
tymi typami danych, które są dość skomplikowane a wartwą prezentacji. 
Warstwa serviceLayer może mieć kilka api i każde api musi być dość jasne, 
przejrzyste, dać się łatwo modyfikować i testować.

Co wymyśliłem? Jedno z api, które produkuje serviceLayer będzie to api do 
zarządanie aplikacją - panel admina (to jest tylko przykład, nie rzeczywisty 
kod):

interface AdminPanelApi
{
    IDictionary<string, object> GetUsers(GetUsersRequired, 
GetUsersOptional);
    IDictionary<string, object> GetSomeObjects(GetSomeObjectsRequired, 
GetSomeObjectsOptional);
}

Co na tym widać:
- Wszystkie metody zwracają dokładnie i zawsze to samo, czyli drzewo 
IDictionary<string, object>, gdzie object może być typem prostym lub 
następnym IDictionary<string, object>.
- Każda metoda na wejściu ma dedykowane 2 obiekty: <nazwa metody>Required i 
<nazwa metody>Optional. Po co? W pierwszym są dane, które muszą być, aby 
wywołanie miało sens. Drugie są opcjonalne, gdzie każda właściwość może być 
nullem. Jeśli dojdzie jakaś własność, to łatwo to będzie zmodyfikować, 
udokumentować, zwalidować i serializować. Typy wejściowe nie są drzewiaste: 
mogą zawierać proste typy i proste kolekcje.
- Dodanie każdej metody, to: wpisanie nagłówka do interfacu, 
zaimplementowanie metody, napisanie 2 klas i udokumentowanie jakie klucze 
będą zwracane.

Zalety:
- łatwo modyfikowalne,
- łatwo zrozumiałe,
- IDictionary<string, object> można łatwo przerobić na Jsona, xmla lub 
cokolwiek w przypadku napisania web servicu korzystającego z serviceLayer,
- w zależności od poziomu dostępu wywołującego metodę i danych wejściowych 
IDictionary<string, object> może zawierać czasem mniej lub więcej kluczy - 
to musi być w dokumentacji co od czego zależy.

Wady:
- Typ IDictionary<string, object> nie jest jasno opisany przez kod - 
potrzeba pracy z dokumentacją.

I teraz główne pytania:
- Czy to ma sens?
- Czy ktoś już pisał coś podobnego i natrafił na lepsze rozwiązanie?
- Gdzie znajde jakieś informacje best practice jak się piszę porządne api, 
które może się rozrastać bez końca?

Pozdrawiam.

M.