Temat: Dobre praktyki w zakresie korzystania z usług (np. WCF) z...

Witam,

mam pytanie o dobre praktyki w zakresie "konsumowania" usług z poziomu ASP.NET.
Konkretnie chodzi mi o następujący hipotetyczny scenariusz:
1. Tworzę nową aplikację z interfejsem web-owym.

2. Chcę być modny i zrobić aplikację opartą o "SOA" :-).

3. W procesie biznesowym wspomaganym przez system jest operacja
"Rejestruj wniosek", wiążąca się z zarejestrowaniem dużego zestawu danych (powiedzmy że 250 - 500 pól dotyczących kilku encji - szczegółowe dane kilku autorów wraz z publikacjami). Operacja ta ma być odwzorowana jako metoda (metody) usługi.

4. Liczba pól wymaganych przez metodę "Rejestruj wniosek" jest tak
duża, że praktycznie nie ma możliwości wprowadzenia wszystkich wymaganych danych na pojedynczym formularzu.

5. Oprócz metody "Rejestruj wniosek" usługa będzie posiadała metody pozwalające na modyfikowanie zarejestrowanych danych wniosku.

I tutaj pojawia się moje pytanie o to, jak powinien wyglądać interfejs takiej usługi aby był zarówno "poprawny", jak i efektywny?

Jeśli będę chciał być "purystą", to zrobię w usłudze 2 metody: "Rejestruj wniosek" i "Modyfikuj wniosek", które będą operowały na całości danych tego wniosku. Jednak wtedy, ponieważ
dane nie mieszczą się na pojedynczej formatce ASP.NET, będę musiał wprowadzić jakiś dodatkowy mechanizm ich buforowania po stronie aplikacji. Trzymanie dużej ilości danych w sesji jest zdecydowanie złą praktyką jeśli chodzi o tworzenie aplikacji ASP.NET, z kolei tworzenie po stronie aplikacji ASP.NET dedykowanego "magazynu" na dane wniosku przed ich wysłaniem do usługi wydaje się być nadmiarowe. Pomijam już fakt, że każdorazowa edycja pojedynczego pola wniosku będzie się wiązała z przesłaniem do usługi pełnego zestawu danych.

Z drugiej strony mogę zrobić w usłudze szereg metod, wykonujących operacje na podzbiorze danych wniosku (np. "Rejestruj
wniosek", "Dodaj autora", "Usuń autora", "Edytuj autora", "Dodaj
publikację", "Usuń publikację" itp.)
Takie rozwiązanie wydaje się jednak być typowym przykładem "CRUD-owego" interfejsu usługi, co jest złą praktyką w przypadku
rozwiązań SOA.

Pewnie możliwych rozwiązań jest więcej. I tutaj proszę o pomoc - jakie rozwiązanie będzie w tym wypadku zgodne ze sztuką i dobrymi praktykami - zarówno jeśli chodzi o budowę aplikacji ASP.NET, jak i warstwy usługowej?Jarosław Szczegielniak edytował(a) ten post dnia 14.07.08 o godzinie 17:54

Temat: Dobre praktyki w zakresie korzystania z usług (np. WCF) z...

Usługi i metody przez nie wykonywane powinne być jak najbardziej autonomiczne. Kolejna operacja nie powinna zależeć od wykonania poprzedniej. Najlepszym rozwiązaniem jest wykonanie pojedynczej metody z encją obiektu biznesowego jako parametr. Ponieważ sytuacja jest jednak nietypowa (obiekt ma kilkadziesiąt pól), możesz rozważyć przekazanie np. kilku "podobiektów", poza tym główny obiekt może się mieć inne obiekty jako pola. Jednak należy pamiętać o tym, aby usługa była wywoływana jak najmniej razy, a najlepiej TYLKO raz, na końcu wypełniania wniosku. A obiekt pomiędzy requestami (jeżeli tak jak piszesz masz kilka formatek), można przechowywać np. w sesji, lub np. po stronie klienta. Pamiętaj tylko, żeby taki obiekt był serializowalny.

Temat: Dobre praktyki w zakresie korzystania z usług (np. WCF) z...

Dziękuję za odpowiedź.

Załóżmy jednak, że proces biznesowy wspomagany przez usługę wiąże się nie tylko z samą rejestracją, ale i z obiegiem wniosku (w którym uczestniczą różni aktorzy - zarówno ludzie jak i inne systemy), trwającym nawet kilka tygodni.

W trakcie trwania obiegu, dane wniosku mogą być uzupełniane i edytowane (w zakresie zależnym od aktualnego stanu obiegu i roli aktora dokonującego zmiany).

Tutaj z definicji nie ma mowy o pełnej autonomii - edycja wniosku wymaga, aby został wcześniej zarejestrowany, dodatkowo możliwa zmiana stanu wniosku zależy od wcześniej podjętych w obiegu decyzji.

Czy w takim wypadku nadal należy operować na całym obiekcie wniosku, czy też lepiej będzie po stronie usługi przewidzieć metody operujące na podzbiorach jego danych (np. osobne metody do rejestrowania uwag do wniosku, osobne do edycji jego danych, wreszcie osobne do modyfikacji jego stanu)?

Temat: Dobre praktyki w zakresie korzystania z usług (np. WCF) z...

Zasada pozostaje bez zmian. Usługi powinne być autonomiczne. Poprzez autonomie mam na myśli, że nie są bezpośrednio ze sobą powiązane od strony architektury systemu. Nie przeszkadza to w niczym aby były częśćią tego samego procesu biznesowego, którego stan jest częścią ich logiki biznesowej. To samo tyczy się "CRUDD'owego" interfejsu. Należy go unikać. Usługi powinne otrzymywać dane potrzebne do wykonania zaimplementowanej funkcjonalności i zwracać oczekiwane dane, w jednoznaczej konsystentnej postaci. Najlepiej poprzez obiekty implementujące zdefiniowane dla tej usługi kontrakty. Nie oznacza to w tym przypdaku, że za każdym razem masz operować na całym obiekcie wniosku (byłby to także antywzorzec). Chodzi o utworzenie obiektów reprezentujących "podzbiory danych" pobieranych i zwracanych przez tą usługę. Podstawą jest tutaj prawidłowe zaprojektowanie struktury usług i zdefiniowanie ich kontraktów. Nie ma na to złotego środka. Wszystko zależy od wymagań biznesowych. Jakie systemy będą konsumentami konkretnych serwisów, kto ma jakie prawa dostępu do określonych usług i szereg innych czynników.

Temat: Dobre praktyki w zakresie korzystania z usług (np. WCF) z...

Polecam przy okacji ten artykuł: http://msdn.microsoft.com/en-us/library/ms954638.aspx

Temat: Dobre praktyki w zakresie korzystania z usług (np. WCF) z...

Dziękuję za odpowiedź.

Podsumowując pozostaje intuicja poparta doświadczeniem - a podstawą jest to, aby usługi i ich metody odzwierciedlały logikę procesu biznesowego, a nie technologię klienta, który będzie je "konsumował".

Temat: Dobre praktyki w zakresie korzystania z usług (np. WCF) z...

Dokładnie. Technologia klienta może mieć wpływ na pewne sprawy podczas implementacji (im mniej tym lepiej) i konfiguracji, natomiast nie powinna wpływać na wartstwe logiczną usług. Stąd właśnie podział na kontrakty i konkretną implementacje/instancje (nie mogę znaleźć lepszego słowa, w wypadku WCF mogą to byc np. endpointy)...Michał Miszczyszyn edytował(a) ten post dnia 17.07.08 o godzinie 09:54