Каковы преимущества и недостатки использования уровня Data Services?

Question

Это обсуждение, которое, похоже, регулярно появляется в мире SOA. Я слышал это еще в 95 году, но, вероятно, это было предметом разговора задолго до этого. У меня определенно есть собственное мнение по этому поводу, но я хотел бы услышать несколько хороших и убедительных аргументов в пользу наличия уровня служб данных, а также аргументов против его наличия.

Какую ценность это добавляет к системной архитектуре? Каковы присущие подводные камни? Каковы общие анти-паттерны?

Ссылки на статьи безусловно приемлемы.

Чтобы избежать путаницы, эта статья описывает тип уровня обслуживания данных, о котором я говорю. По сути, это тонкий слой над базой данных, который обеспечивает SOAP-доступ к данным и не содержит бизнес-логики.

Answer 1

Службы данных достаточно ориентированы на данные, поскольку проекты без логики всегда делают грубость.Например, это может подойти, если у вас есть служба журналов или служба свойств, вы просто сделаете ей все возможное.

Если домен, который включает этот DDBB, является сложным, со сложной логикой, вам потребуетсяуправляйте этой логикой вплоть до этой службы (возможно, в оркестровке), чтобы разделить логику на несколько служб.В этом случае я думаю, что лучше использовать более толстую уникальную службу (DAL, BLL и SIL), которая управляет этим доменом и предоставляет только один интерфейс.

В конце концов, это другой инструмент, в зависимости от проблемы.