OData WCF Data Service with NHibernate and corporate business logic -

let me first apologise length of entire topic. long, wish sure message comes on without errors.

here @ company, have existing asp.net webapplication. written in c# asp.net on .net framework 3.5 sp1. time ago initial api developed web application using wcf , soap allow external parties communicate application without relying on browsers.

this api survived time, request came create new api restfull , relying on new technologies. given assignment, , created initial api using microsoft mvc 2 framework, running inside our asp.net webapplication. took quiet time running, @ moment we're able make rest calls on application receive xml detailing our resources.

i've attended microsoft webcamp, , immediatly sold odata concept. similar doing, protocol supported more players instead of our own implementation. i'm working on poc (proof of concept) recreate api developed using odata protocol , wcf dataservice technology.

after searching internet getting nhibernate 2 work data services, succeeded in creating readonly version of api allows read out entities internal business layer mapping incoming query requests our business layer. however, wish have functional api allows creation of entities using odata protocol. i'm bit stuck on how proceed. i've been reading following article : http://weblogs.asp.net/cibrax/default.aspx?pageindex=3

the above articly nicely explains on how map custom dataservice nhibernate layer. i've used base continue on, have "problem" don't want map requests directly database using nhibernate, wish map them our business layer (a seperate dll) performs large batch of checks, constraints , updates based upon accessrights, privledges , triggers.

so want ask, example create own nhibernatecontext class in above articly, instead rely on our business layer instead of nhibernate sessions, work? i'd have rely on reflection alot figure out type of object i'm working @ runtime , call correct business classes perform updates , deletes.

to demonstrate smal ascii picture:

                              *-----------------*                               *   database      *                               *-----------------*                                *------------------------*                               * dal(data access layer) *                               *------------------------*                                *------------------------*                               * bul (bussiness layer)  *                               *------------------------*                               *---------------*  *-------------------*                               * odata stuff*  * internal api      *                               *---------------*  *-------------------*                                                   *------------------*                                                  * web application  *                                                  *------------------* 

so, work, or performance make useless? or missing ball here? idea wish reuse whatever logic stored in bul & dal layer odata wcf dataservice.

i thinking creating new classes inherit entitymodel classes in data.services namespace , create new dataservice object marks calls bul & dal & api layers. i'm not sure where/who intercept requests creating , deleting resources.

i hope it's bit clear i'm trying explain, , hope can me on this.

the devil in details, sounds design you're proposing should work.

the dataservice class define access rights applicable everyone, configuration settings, , custom operations. in scenario, think focusing more on data context instead (the 't' in dataservice).

for context, there 2 interesing paths: reads , writes. reads happen through iqueryable entry points. writing linq provider chunk of work, nhibernate supports this, although return imagine we're calling dal entities. can use query interceptors access checks here if can express in terms database understand.

the update path understand trying run more business logic (you mentioned validation, updates, etc). this, you'll want focus on iupdatable implementation (idataserviceupdateprovider if you're using latest version). here can use whichever objects want - dal objects or business objects. can in dal , run validation on savechanges(), or on business objects if validate go.

there 2 places might 'jump' 1 kind of objects another. 1 in getresource() api, iqueryable, presumably in term of dal entities. other in resolveresource(), runtime asking object serialize, iqueryable, it's presumably dal entity.

hope helps - doing uniform access on non-uniform apis can hard, worth it!