Архитектура на уеб услугите - Множество услуги и множество връзки с бази данни? - уеб услуги

Може ли някой да ме насочи към някаква стокадокументация или обратна връзка тук какви са най-добрите практики за внедряване на уеб услуги в приложение, което се справя с различни проблеми? Например, трябва ли да създам различни услуги, които обработват сигурност, (AuthService), такава, която обработва въвеждането на данни за повторения на обслужване на клиенти, (CRUDService), BillingService и така нататък или трябва просто да капсулирам всички тези „услуги“ в едно, напр ApplicationService? По принцип питам дали е лош дизайн да се създават множество услуги (файлове) в рамките на едно приложение. Може ли някой от вас да отбележи вашите преживявания или какво сте преживели? Също така, нека да кажем, че три от изброените по-горе услуги се свързват към една и съща база данни, но всъщност засягат абсолютно различни проблеми, например една е за всички транзакции като CRUD, а другата е за чисто отчитане. Трябва ли да създам две услуги тук, една CRUDService и другата за ReportingService? Лошо ли е да създадете две различни връзки към база данни чрез тези 2 услуги? Или как мога да споделя една и съща връзка с база данни с различни услуги?

Отговори:

Мисля, че има тенденция сред публичноналични услуги, за да зарежете всичко в една услуга. Което може да не е лоша идея за публично достъпен API. Той просто улеснява разработчиците. Въпреки това, за всеки проект, върху който работя, се опитвам да разделям нещата на логически групи. По този начин клиентът ви не трябва да наследява функционалността, която може да не се нуждае. Актуализирането на услугите също ще бъде малко по-лесна задача, защото вие засягате само определен подмножество от рамката на вашата уеб услуга, а не всичко. Така че, ако договорът ви за услуга се счупи и клиентите ви вече не го поддържат, те все още могат да използват други части на вашата система, но не тази конкретна. Където, като че ли нарушите договор за своята обобщена услуга, всичко се проваля. И накрая, ако трябва да внедрите нещо като поддръжка за отказ, имате по-голяма гъвкавост да изберете коя услуга изисква повече възли за отказ, което ви позволява да управлявате по-добре разпределението на ресурсите си.

Ако искате най-добри практики, разгледайте Каталог на модели на SOA дизайн