OData WCF Data Service с NHibernate и корпоративной бизнес-логикой
Позвольте мне сначала извиниться за длину всей темы. Это будет довольно долго, но я хочу быть уверенным, что сообщение приходит ясно, без ошибок.
Здесь, в компании, у нас есть веб-приложение ASP.NET. Написано в C# ASP.NET на платформе.NET Framework 3.5 с пакетом обновления 1 (SP1). Некоторое время назад для этого веб-приложения был разработан начальный API-интерфейс, использующий WCF и SOAP, чтобы внешние стороны могли взаимодействовать с приложением, не полагаясь на браузеры.
Этот API просуществовал некоторое время, но в итоге пришел запрос на создание нового API, который был бы RESTfull и опирался на новые технологии. Мне дали это назначение, и я создал начальный API, используя Microsoft MVC 2 Framework, работающий внутри нашего ASP.NET WebApplication. Первоначально потребовалось некоторое время, чтобы правильно его запустить, но в данный момент мы можем сделать REST-вызовы приложения, чтобы получить XML, детализирующий наши ресурсы.
Я посетил Microsoft WebCamp, и я сразу же был продан концепцией OData. Это было очень похоже на то, что мы делаем, но это был протокол, поддерживаемый большим количеством игроков, а не нашей собственной реализацией. В настоящее время я работаю над PoC (Proof of Concept), чтобы воссоздать API, который я разработал с использованием протокола OData и технологии WCF DataService.
После поиска в Интернете, чтобы заставить NHibernate 2 работать со службами данных, мне удалось создать версию API ReadOnly, которая позволяет нам считывать сущности из внутреннего бизнес-уровня путем сопоставления входящих запросов на наш бизнес-уровень. Однако мы хотим иметь функциональный API, который также позволяет создавать объекты с использованием протокола OData. Так что теперь я немного застрял на том, как действовать. Я читал следующую статью: http://weblogs.asp.net/cibrax/default.aspx?PageIndex=3
Вышеприведенные статьи хорошо объясняют, как сопоставить пользовательский DataService со слоем NHibernate. Я использовал это в качестве основы для продолжения, но у меня есть "проблема" в том, что я не хочу отображать свои запросы напрямую в базу данных с помощью NHibernate, но я хочу отобразить их на наш бизнес-уровень (отдельная DLL).), которая выполняет большую серию проверок, ограничений и обновлений на основе прав, привилегий и триггеров.
Итак, что я хочу спросить, я, например, создаю свой собственный класс NhibernateContext, как показано выше, но вместо этого полагаюсь на наш бизнес-уровень вместо сеансов NHibernate, может ли он работать? Мне, вероятно, придется полагаться на размышления, чтобы выяснить тип объекта, с которым я работаю во время выполнения, и вызвать правильные бизнес-классы для выполнения обновлений и удалений.
Чтобы продемонстрировать маленькую картинку ascii:
*-----------------*
* Database *
*-----------------*
*------------------------*
* DAL(Data Access Layer) *
*------------------------*
*------------------------*
* BUL (Bussiness Layer) *
*------------------------*
*---------------* *-------------------*
* My OData stuff* * Internal API *
*---------------* *-------------------*
*------------------*
* Web Application *
*------------------*
Итак, будет ли это работать, или производительность сделает его бесполезным? Или я просто скучаю по мячу здесь? Идея состоит в том, что я хочу повторно использовать любую логику, хранящуюся на уровне BUL & DAL из OData WCF DataService.
Я думал о создании новых классов, которые наследуются от классов EntityModel в пространстве имен Data.Services, и создания нового объекта DataService, который отмечает все вызовы для уровней BUL & DAL & API. Однако я не уверен, где / кому перехватывать запросы на создание и удаление ресурсов.
Я надеюсь, что немного понятно, что я пытаюсь объяснить, и я надеюсь, что кто-то может помочь мне в этом.
1 ответ
Дьявол кроется в деталях, но звучит так, будто предлагаемый вами дизайн должен работать.
Класс DataService - это место, где вы можете определить права доступа, применимые ко всем, параметры конфигурации и пользовательские операции. В этом сценарии, я думаю, вы будете больше фокусироваться на контексте данных ("T" в DataService).
Для контекста действительно есть два интересных пути: чтение и запись. Чтение происходит через точки входа IQueryable. Написание поставщика LINQ - хороший кусок работы, но NHibernate уже поддерживает это, хотя он вернул бы то, что, как я думаю, мы называем DAL-объектами. Вы можете использовать перехватчики запросов для проверки доступа, если вы можете выразить их в терминах, понятных базе данных.
Я понимаю, что путь обновления основан на том, что вы пытаетесь использовать больше бизнес-логики (вы упомянули проверку, дополнительные обновления и т. Д.). Для этого вам нужно сосредоточиться на реализации IUpdatable (IDataServiceUpdateProvider, если вы используете последнюю версию). Здесь вы можете использовать любые объекты, которые вам нужны - это могут быть объекты DAL или бизнес-объекты. Вы можете делать все в DAL, а затем запускать проверку в SaveChanges() или делать все в бизнес-объектах, если они проверяются по ходу.
Есть два места, где вы можете "прыгать" с одного вида объектов на другой. Один из них - в API GetResource (), где вы получаете IQueryable, предположительно в терминах объектов DAL. Другой - в ResolveResource(), где среда выполнения запрашивает сериализацию объекта, точно так же, как это было бы из IQueryable, так что это, предположительно, также объект DAL.
Надеюсь, это поможет - сделать унифицированный доступ через неоднородные API-интерфейсы может быть сложно, но часто оно того стоит!