Включение ORM в (полу) архитектуру SOA

Question

Я изучаю предложения ORM (сосредотачиваясь на NHibernate, учитывая все варианты) и убежден, что использование одного может быть большим преимуществом для некоторых наших проектов - однако мне трудно представить, как это будет играть в нашей системе.

Насколько я понимаю, ORM идеально используется для склейки базы данных и бизнес-логики. Это предполагает, что бизнес-логика имеет доступ к базе данных, но в нашей системе веб-сервисы застряли посередине.

Наша нынешняя система довольно проста. Мы .NET через все и имеют:

• Базы данных. С таблицами ... и строками.
  • Разрешения ограничены правами на выполнение для sprocs, мы создаем sprocs с базовой проверкой, и ничто не входит в базу данных или из нее без прохождения sproc.
• WebServices
  • Выполнять операции CRUD для sprocs БД
  • В настоящее время обычно используют DataSets / DataTables для своих сообщений
• Бизнес-логика
  • Переговоры с веб-сервисами

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

Итак, мой набор вопросов:

• Этот подход работает?

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

• Существует ли другая реализация, которая бы помещала часть взаимодействия ORM на стороне клиента веб-службы (попросите клиента запросить объект у поставщика ORM и попросите поставщика ORM обернуть связь веб-службы) )

• Наша текущая единица работы сосредоточена на DataTables и их отслеживании состояния строки.

  • Какую часть отслеживания состояний будет предоставлять ORM, когда мы помещаем веб-сервис между ним и бизнес-логикой?
  • Требуются ли для отображения объектов, которые мы отображаем, собственное отслеживание состояния?

Answer 1

Ваш веб-сервис и слои хранимых процедур уже выполняют большую часть работы, которую выполнял бы ORM низкого уровня: доступ к базе данных строго типизированным способом. Похоже, вы получаете DataTables обратно из веб-службы, и вы хотите инкапсулировать эти DataTables в классы.

Вы получите очень небольшую помощь от возможностей "автоматического создания", которые предоставляет большинство продуктов ORM, поскольку они обычно ориентированы на создание классов непосредственно из источника SQL. С другой стороны, если ваши веб-сервисы разрешают обнаружение возвращаемых столбцов, создание таких классов-оболочек из традиционных методов генерации кода - не сложный проект. Если эти сгенерированные классы основаны на базовых типах вашего ORM, вы можете использовать остальную часть инфраструктуры (коллекции сущностей, единицы работы и т. Д.).

Это довольно сильно отличается от большинства архитектур, которые я видел. Я видел DataStore-> ORM-> Business Logic-> Web Service ==> Потребитель использовал совсем немного. Это позволяет легко писать бизнес-логику в хранилище данных, предоставляя веб-сервисы, которые решают, как использовать бизнес-логику. Потребитель (приложение конечного пользователя, либо настольный компьютер, либо веб-презентация) в основном отвечает за презентацию (как и должно быть в большинстве случаев).

С другой стороны (если я неправильно прочитал), кажется, вас интересует DataStore-> Sproc-> WebServices ===> ORM-> Business Logic-> Consumer. Это не то, что я видел часто. Я думаю, что это работает против вашего принятия ORM так, как вы думаете.

Я что-то упустил или большая часть бизнес-логики действительно выполняется на клиенте?

Answer 2

Я бы рекомендовал не использовать ORM в вашей ситуации, и это исходит от кого-то, кто регулярно использует NHibernate. В текущей настройке вам придется перепрыгивать через несколько обручей, чтобы ваше приложение работало, и вы не сможете воспользоваться большинством функций, которые предоставляет хороший ORM, такой как NHibernate.

• Работа со sprocs и ORM, хотя она и может быть выполнена, сложна в настройке и выстраивает ORM из того, что она делает.
• Постоянство благодаря достижимости является ОГРОМНЫМ преимуществом при использовании NHibernate, но не будет доступно вам, так как ваш уровень домена «отключен».
• NHibernate основан на IDbConnection, поэтому попытка подключить его на стороне клиента через веб-сервис лишит вас возможности использовать Session (Unit of Work)

Если вы пытаетесь передать объекты вместо DataTables, почему бы вместо этого не использовать DTO? Это даст вам строго типизированные объекты, но все равно будет работать в вашей настройке.