OData WCF Data Service с NHibernate и корпоративной бизнес-логикой

Question

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

Здесь, в компании, у нас уже есть ASP.NET WebApplication.Написано в C # ASP.NET на платформе .NET Framework 3.5 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 работать с Data ServicesМне удалось создать версию 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.Однако я не уверен, где / кому перехватывать запросы на создание и удаление ресурсов.

Надеюсь, мне немного понятно, что я пытаюсь объяснить, и я надеюсь, что кто-то может помочь мне в этом.

Answer 1

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

Класс DataService - это место, где вы можете определить права доступа, применимые ко всем, настройки конфигурации и пользовательские настройки.операции.В этом сценарии, я думаю, вы сосредоточитесь больше на контексте данных («T» в DataService).

Для контекста действительно есть два интересных пути: чтение и запись.Чтение происходит через точки входа IQueryable.Написание поставщика LINQ - хороший кусок работы, но NHibernate уже поддерживает это, хотя и вернул бы то, что, как мне кажется, мы называем DAL-сущностями.Вы можете использовать перехватчики запросов для выполнения проверок доступа здесь, если вы можете выразить их в терминах, понятных для базы данных.

Путь обновления основан на том, что, как я понимаю, вы пытаетесь использовать больше бизнес-логики (вы упомянули проверку, дополнительные обновления и т. д.).Для этого вам нужно сосредоточиться на реализации IUpdatable (IDataServiceUpdateProvider, если вы используете последнюю версию).Здесь вы можете использовать любые объекты, которые вам нужны - это могут быть объекты DAL или бизнес-объекты.Вы можете делать все в DAL, а затем запускать проверку в SaveChanges () или делать все в бизнес-объектах, если они проверяются по ходу.

Есть два места, где вы могли бы «прыгнуть» из одного вида объектов.другому.Один из них - в API GetResource (), где вы получаете IQueryable, предположительно в терминах объектов DAL.Другой - в ResolveResource (), где среда выполнения запрашивает сериализацию объекта, точно так же, как это было бы из IQueryable, так что это, предположительно, также объект DAL.Неоднородные API могут быть сложными, но зачастую они того стоят!