I’m building some business objects for a new project and I’m wondering whether it would be best to have the data access code as part of the application, or to put it behind a service. I’ve seen Jeff Atwood praise the idea of using a web service over and over again… this is not for an web application but I think using WCF I can accomplish the same thing.
I know there are several areas to evaluate when making a decision like this each with their own pros and cons and for the most part I feel I have a handle on the trade-offs of each as they relate to our product, except in the area of performance.
For example, there is code to cache the objects… and that works great when doing direct sql access because the objects get cached on the individual machines but the downside is they each have to query the database. On the other hand the service only has to query the database once and then distribute objects but would it be faster/slower for the service to distribute these objects than for the clients to access the db themselves.
If it’s slower then I might have to write additional code on the clientside, such as caching objects they get from the service. The load on the db is not bad with each client accessing it directly, so I don’t know if that would be worth the additional effort. But if it’s super fast then it could make it easier for me to manage the issues related to having distributed objects.
I hope I’m not be to general here and I can try to improve this question if necessary, but I believe this pretty much conveys what I’m trying to ask.
Have you considered looking at distributed caching rather than a traditional data layer?
Something like memcached – Is there a port of memcache to .Net?