Каковы рекомендуемые подходы для перехода с 2-уровневого NHibernate на 3-уровневый с помощью SOA (Microsoft CRM)?

Question

Учитывая (текущий) проект, который реализует 2-уровневую архитектуру с хорошо разделенным на уровне уровня бизнес-уровнем, следуя типичной общей архитектуре DAO, впервые предложенной Биллом МакКафферти для CodeProject и кратко объясненной в главе10 из NHibernate в действии.

Этот проект необходимо перенести для выполнения операций CRUD и бизнес-логики через Microsoft CRM в качестве промежуточного уровня с использованием веб-служб.Пользовательские объекты и методы определены в CRM, чтобы имитировать текущую ситуацию.

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

Реализация DTO кажется правильной причиной действий, но требует длинного пути (плюс путь обучения для команды).Ранее я занимался SOA-проектами, но сейчас я ищу путь наименьшего сопротивления.Можем ли мы продолжать использовать NHibernate, даже если прямое подключение к БД не будет возможным?Придется ли нам переосмыслить проект, или, возможно, вариант, представленный в .NET 4.0, является автономным?Насколько безболезненно это может стать?

Answer 1

Взгляните на MS CRM SDK 4.0.12, в Reflector тоже.Они прошли довольно долгий путь к правильному ORM, включая CRUD и Linq.Там есть много тонких (и не очень тонких) различий с NH, и он еще не обучен плагину, но, по крайней мере, вы можете позаимствовать некоторые идеи.

Answer 2

Мы используем XRMLinq - http://www.xrmlinq.com. Он создает ваши объекты DTO, и вы можете использовать синтаксис LINQ для запроса к ним.Платформа автоматически преобразует ваши запросы LINQ в запросы FetchXML к веб-сервисам CRM.Объекты DTO создаются как частичные классы, поэтому вы можете добавить свою собственную логику, которая будет выдерживать регенерации.

Другой совет: по возможности используйте настраиваемые действия рабочего процесса для своей бизнес-логики.Вместо того, чтобы писать логику непосредственно в DTO, который генерирует XRMLinq, рассмотрите возможность создания настраиваемой операции рабочего процесса, которая будет запускаться при обновлении определенных полей.Это заставляет вашу бизнес-логику работать, даже если эти поля обновляются где-то еще в системе (не через вашу собственную логику DTO).Это также дает вам хорошую систему очередей и механизм восстановления после сбоев - если ваша пользовательская активность рабочего процесса выдает исключение, рабочий процесс «приостанавливается» до тех пор, пока вы не решите проблему, после чего вы можете просто возобновить рабочие процессы, которые потерпели неудачу.Это работает только для бизнес-логики, которая, очевидно, может выполняться асинхронно, но для синхронной логики я все равно рекомендую просмотреть пользовательские плагины перед записью логики в DTO.

Надеюсь, это поможет!

Answer 3

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

http://hubpages.com/hub/Building-Service-Orientated-Architecture