Доступ к данным архитектуры SOA

Просто мое личное мнение: если вы создаете службу для доступа ко всем базам данных, тогда несколько служб зависят от ОДНОЙ службы, что как бы побеждает точку SOA (т. Е. Службы автономны), как вы сформулировали. Когда вы говорите о дублировании уровней, если каждый сервис имеет свои собственные данные для обработки, действительно ли это дублирование. Я понимаю, что у вас, вероятно, есть те же самые средства взаимодействия с вашими реляционными базами данных, или еще со времен OOA у вас была общая библиотека классов, которая инкапсулировала доступ к данным для вас. Это одна из тех вещей, с которыми я борюсь сам, но я не вижу проблемы в том, чтобы у каждой службы был свой собственный уровень данных. Фактически, в книга Мишель Бустаманте (глава 1, стр. 8) — она на самом деле изображает это и добавляет: «Службы инкапсулируют бизнес-компоненты и доступ к данным». Если вы заметили, что у каждой службы есть отдельный уровень DALC. Это хороший вопрос.

Звучит так, как будто у вас есть несколько сервисов, но одна база данных.

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

Добавление дополнительного слоя WCF только усложнит и замедлит ваше решение.

Я бы порекомендовал вам создать единую dll доступа к данным, которая содержит весь доступ к данным и на которую ссылается каждая служба WCF. Таким образом, у вас не будет дублирования кода. Поскольку у вас есть одна база данных, любое изменение в базе данных/слое данных в любом случае потребует повторного развертывания всех служб.

Почему бы просто не использовать структуру внедрения зависимостей и, если они в настоящее время используют одну и ту же базу данных, просто разрешить им совместно использовать один и тот же код, и если бы они были в одном проекте, то все они использовали бы одну и ту же DLL.

Таким образом, позже, если вам нужно будет добавить какой-то код, которым вы не хотите делиться с другими, вы можете внести изменения и просто создать новый слой DAO.

Если есть определенный синглтон, который будут использовать все, то вы можете просто внедрить его при вставке в слой dao.

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

Настоящая победа, которую приносит SOA, заключается в том, что она уменьшает количество связей между приложениями.

В прошлом я работал с организациями, которые делали это разными способами. Некоторые слои данных интегрированы, а некоторые абстрагированы.

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