Peter said:
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
