Доступ к данным архитектуры SOA
Я вытираю его и устанавливаю Linux. Все всегда поражаются тем, насколько продуктивный я могу быть. Это - потому что я не трачу половину моего времени, борясь с машиной.
4 ответа
Лично я считаю, что если вы создаете службу для всего доступа к базе данных, тогда несколько служб будут зависеть от ОДНОЙ службы, которая как бы нарушает суть SOA (т.е. службы являются автономными), как вы сформулировали . Когда вы говорите о дублировании слоев, если каждая служба имеет свои собственные данные, то действительно ли это дублирование? Я понимаю, что у вас, вероятно, есть те же средства взаимодействия с вашими реляционными базами данных, или еще со времен OOA у вас была общая библиотека классов, которая инкапсулировала доступ к данным для вас. Это одна из тех вещей, с которыми я борюсь с собой, но я не вижу проблем в том, чтобы каждая служба имела свой собственный уровень данных. Фактически, в книге Мишель Бустаманте (Глава 1 - Страница 8) она фактически изображает это и добавляет «Сервисы инкапсулируют бизнес-компоненты и доступ к данным». Если вы заметили, у каждой службы есть отдельный слой DALC. Это хороший вопрос.
Похоже, у вас есть несколько служб, но одна база данных.
Если это правильно, у вас действительно нет чистой архитектуры SOA, поскольку службы не являются независимыми. (Нет ничего плохого в отсутствии чистой архитектуры SOA, часто это может быть правильный выбор)
Добавление дополнительного уровня WCF только усложнит и замедлит ваше решение.
Я бы порекомендовал вам создать отдельные данные access dll, которая содержит все возможности доступа к данным и на которую ссылается каждая служба WCF. Таким образом, у вас не будет дублирования кода. Поскольку у вас одна база данных, любое изменение в базе данных / уровне данных в любом случае потребует повторного развертывания всех служб.
Почему бы просто не использовать структуру внедрения зависимостей, и, если они в настоящее время используют одну и ту же базу данных, просто разрешить им использовать один и тот же код, и если они были в одном проекте, то они все будут использовать одну и ту же dll.
Таким образом, позже, если вам понадобится вставить какой-то код, который вы не хотите, чтобы другие делили, вы можете внести изменения и просто создать новый слой DAO.
Если есть определенный синглтон, который все будут использовать, тогда вы можете просто ввести его, когда вы вводите в уровень dao.
Но для этого потребуется, чтобы они использовали один и тот же контроллер инфраструктуры DI.
Настоящая победа, которую приносит SOA, заключается в том, что она уменьшает количество связей между приложениями.
В прошлом я работал с организациями, которые делали это разными способами. Некоторые уровни данных интегрированы, а некоторые абстрагированы.
Я видел, как это наиболее успешно выполняется, когда вы создаете общие службы уровня данных для каждого приложения / базы данных и создаете службы более высокого уровня на основе недавно созданного уровня данных.