Re: Using a Web Service for Business Logic BackEnd / Data Layer

Peter Bromberg [C# MVP] wrote:
Not really, but if the webservice and the website are both hosted on the same box, why do you need a webservice? Why not just have your Data layer talk directly to the database - that would certainly be the fastest.

You'd think so but I've been thinking about this a bit myself recently. If you're talking to your databases via something like nNibernate, there's an initialization phase when setting up nHibernate where it builds an map telling it how objects relate to database objects. This is kind of a time consuming process and in a Windows Forms app you'd usually only do this once, when the app was launching. In a Web app, as with a windows app, you're going to have to do this, at the very least, once each time the application domain gets loaded - however the app domain can potentially get loaded a lot more often in Web Apps (and it's not under your direct control when this happens)... and to achieve that "just once" scenario in a web app you need to override the Application_Start() event of the global.asax file and make sure you store a thread safe reference to the object map in a static member that is accessible to all the other threads in your web app (which doesn't sound like it would be too hard).

Alternatively, you can have an NT Service application running a WCF service or something, which takes care of all the DB work and initializes that object map once and only once - when the operating system boots and the service gets loaded. That WCF service is then available to any threads in your web app (maybe via Named Pipes if it's running on the same box, which has fairly minimal overhead aside from the obvious serialization/deserialization) and which, as an added bonus, can also be made available to other processes (potentially on remote clients).

I'm not sure what kind of performance each of the above two architectures would yield comparatively as I haven't tried them both yet with the back end DB code and run any empirical analysis. However I'm currently in the process of building a web app that needs to do a bunch of stuff with databases which I've encapsulated in a MyAppService: IMyAppService class (in a separate assembly). Initially I figured I'd try the path of least resistance and simply add a direct reference to that separate assembly to the web application project and instantiate MyAppService directly in the code for the web app... if that's too slow (which I suspect it will be) I figured I'd go the extra mile and yank out all the stuff that initializes the object map for nHibernate and make sure it gets called in the Application_Start() event of the Global.asax file. If that still doesn't give the desired performance then I'll try the second architecture - add some DataContract and DataMember attributes to the IMyAppService interface and add some WCF configuration sections into the config files of a separate NT Service app (to host the MyAppService service) and the web application which needs to consume this "service".

You can get better performance again with WCF services by using custom binary serializers and the like, so if performance is really key and you're using architecture number 2 then that's always on the cards as well... although it involves writing more code and even though I'm a programmer I'm always a bit loath to actually write code if I can avoid it ;-)

Best Regards,

James Crosswell
Microforge.net LLC
http://www.microforge.net
.

Relevant Pages