Службы данных WCF Как добавить Business Logic или использовать существующие объекты CSLA

Question

Прежде всего, это мой первый вопрос о переполнении стека, поэтому заранее прошу прощения, если я ошибаюсь!

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

Я начал с использования Entity Framework для ORM, CSLA для уровня Business Logic и стандартного сервиса WCF для связи с клиентскими приложениями. Все шло отлично, пока я не взглянул на WCF Data Services и не был соблазнен прекрасным интерфейсом REST, простотой использования клиентами AJAX и радостью от использования новых технологий!

Теперь я заменил большие части служб WCF одной службой данных WCF, которая напрямую предоставляет модель Entity Framework, минуя уровень CSLA. Это прекрасно работает для операций только для чтения, но я не могу выполнять другие функции CRUD без некоторой бизнес-логики.

Я искал Interceptors, и я, конечно, могу поместить туда бизнес-логин, но на самом деле я хочу перехватить операцию POST/Add, сопоставить значения с соответствующим классом CSLA BusinessBase и позволить этому выполнить всю проверку и окончательное сохранение в база данных. Я попробовал это, и хотя объект CSLA работает как задумано, базовая платформа WCF Data Service также сохраняет свою версию, поэтому я получаю две записи в БД.

Поэтому у меня есть несколько вопросов:

1) Могу ли я полностью перехватить запрос на изменение, позволить собственным бизнес-объектам обработать его, а затем отменить службу данных WCF, не вызывая исключения?

2) Существует ли лучший / стандартный подход для добавления уровней бизнес-логики в стек службы данных WCF? Я не смог найти один до сих пор.

Заранее спасибо,

Дейв

Answer 1

К сожалению, если основным провайдером для WCF Data Services является Entity Framework, вы не можете сделать все это самостоятельно. В настоящее время мы не поддерживаем полностью заменяющие части конвейера обработки в этом случае.

С другой стороны, вы можете играть в некоторые трюки. Вы можете сделать это в основном на основе сущности. Последняя версия EF должна позволить вам переопределить вызов SaveChanges так, чтобы вы могли делать там все, что захотите. Таким образом, идея заключается в том, что вы самостоятельно обрабатываете операцию добавления в своем приемнике изменений, а затем в SaveChanges отменяете изменения, созданные службами данных WCF, и отправляете изменения только из перехватчика изменений. Или, может быть, даже лучше, просто сделайте все в SaveChanges.

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

В настоящее время перехватчики являются стандартным способом наложения бизнес-логики на службы данных WCF (которые работают для любого поставщика, включая EF).

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