Architektura usług internetowych - wiele usług i wiele połączeń z bazą danych? - usługi internetowe

Czy ktoś może polecić mi coś dobrego?dokumentacja lub opinia o tym, jakie są najlepsze praktyki dotyczące wdrażania usług internetowych w aplikacji, która obsługuje różne problemy? Na przykład, czy powinienem tworzyć różne usługi, takie, które obsługują zabezpieczenia (AuthService), takie, które obsługują wprowadzanie danych dla przedstawicieli obsługi klienta, (CRUDService), BillingService i tak dalej, czy powinienem zamknąć te wszystkie "usługi" w jednym, na przykład ApplicationService? Zasadniczo pytam, czy to źle zaprojektować tworzenie wielu usług (plików) w ramach jednej aplikacji. Czy niektórzy z was mogą zauważyć twoje doświadczenia lub doświadczenia? Załóżmy też, że trzy z wymienionych powyżej usług łączą się z tą samą bazą danych, ale faktycznie trafiają w zupełnie inne problemy, np. Jedna dotyczy wszystkich transakcji, takich jak CRUD, a druga służy wyłącznie do celów sprawozdawczych. usługi, jedna usługa CRUDService i druga usługa ReportingService? Czy tworzenie dwóch różnych połączeń z bazami danych za pośrednictwem tych dwóch usług jest złe, lub w jaki sposób mogę udostępnić to samo połączenie z bazą danych innym usługom?

Odpowiedzi:

Myślę, że wśród publiczności jest tendencjadostępne usługi, aby po prostu zrzucić wszystko do jednej usługi. Co może nie być złym pomysłem na publicznie dostępny interfejs API. Ułatwia to programistom. Jednak w przypadku każdego projektu, nad którym pracuję, staram się podzielić rzeczy na grupy logiczne. W ten sposób twój klient nie musi dziedziczyć funkcji, której może nie potrzebować. Aktualizowanie usług również byłoby nieco łatwiejsze, ponieważ wpływasz tylko na pewien podzbiór struktury usług internetowych, a nie na wszystko. Jeśli więc umowa o świadczenie usług zostanie zerwana, a klienci nie będą już jej wspierać, mogą nadal korzystać z innych części systemu, ale nie z tej konkretnej. Gdzie tak, jakbyś złamał umowę na twoją usługę zbiorczą, wszystko zawiedzie. Na koniec, jeśli musisz zaimplementować coś w rodzaju wsparcia awaryjnego, masz większą swobodę wyboru, która usługa wymaga większej liczby węzłów typu fail-over, co pozwala lepiej zarządzać alokacją zasobów.

Jeśli chcesz najlepszych praktyk, spójrz na Katalog wzorców projektowych SOA