Принципы проектирования SOA в отношении отношений с базой данных

Question

Если бы я выбрал моего текущего поставщика членства из моего решения, т.е. как dll, и выставил бы его как веб-сервис со своим собственным db, как бы я смоделировал отношения в отношении дизайна SOA.

Например

У меня есть таблица:

USER идентификатор, имя, фамилия, имя пользователя, пароль, роль.

и таблица

ПРОДУКТ

id, name, price, createdate, userid

внешний ключ является идентификатором пользователя для пользователя таблицы.

Как бы я смоделировал отношения и / или запросил бы БД.

Если бы я хотел получить все товары, которые были загружены сегодня, например, прежде чем я бы запросил:

SELECT u.name, u.lastname, u.username, p.* FROM PRODUCT p INNER JOIN USER u ON p.userid = u.id WHERE createdate = '05/05/2010'

Теперь, когда у меня нет таблицы в базе данных, как мне выполнить этот запрос?

Answer 1

Я бы выбрал совершенно другой подход.

Вы часто обнаруживаете, что когда программисты пишут встроенный динамический sql, они получают только чтение данных.Поэтому, почему вы хотите заполнить тяжелые бины сущностей, которые могут возвращать n строк, когда вам нужен только доступ только для чтения?Это особенно верно, если вы имеете дело с веб-сервисами.

Вместо этого я использую подход службы данных CRUD, которая возвращает single, и набор объектов EJB, скажем product, и для запросов только для чтения мне нужна служба поиска.Который принимает имя поиска скажет 'LookupAllProductsUploadedToday' и отображает его в хранимый в БД proc (исключая необходимость в ужасном динамическом sql!), Возвращенный набор данных затем превращается в bean-компонент поиска, который в основном представляет собой набор пар ключ / значение, и отправляетсявне службы для приложения.

Я предпочитаю хранимые процессы по сравнению с встроенным SQL из соображений безопасности, так как тогда вы можете только предоставить права на чтение и выполнение сохраненным процессам и запретить доступ к выполнению динамических операторов SQL.Я разработал различные SOA-приложения, и мне не нужно было писать какие-либо встроенные SQL-файлы с таким подходом.

Answer 2

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

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

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