To Remote or Not to Remote?
Forgive me if my terminology is not 100% correct.
After developing software (all Windows form apps) for many years for small companies, I recently crawled out from underneath my rock and discovered the concept of Remoting and/or WCF. In all the projects I've worked on in the past, we've always had each of the client machines connect directly to a database server. It's recently occured to me, after reading "Microsoft .Net: Architecting Applications for the Enterprise", that it might make more sense to expose our business objects as POCO objects via WCF, that way our client application would not need the database client software installed on each machine (all that goes with it, like another db user license per machine). Our client app would only have to connect to our WCF service that possible exposes a "Service Layer" as a wrapper around our business objects.
Am I crazy, or is this a common approach in distributed applications?
And further, what ORM solution could be pointed at a database and create a DAL and business objects that can then be exposed via WCF?
I also can't quite wrap my mind around how lazy loading would work in this scenario...
Thanks, Jonathan
I'm going to leave the ORM question for others, and only answer the portion of the question asking if this is a common approach.
It's a common approach, called SOA (Service-Oriented Architecture). It has many advantages, and also pitfalls. It was all the buzz a few years back, and now it's still commonly used, but the excitement level has dropped off.
Still, there are tons of resources on the web to research this. The biggest catch is to think ahead because different people have different ideas of how SOA should be implemented, and what it means. Also, the cross-platform promises are harder to achieve in practice than people originally hoped. (try calling .NET Web services from Java, for example. it can be done, but there is work to be done on both sides to make it work.) SO if you EVER need to worry about cross-platform compatibility, research "SOA Cross-platform compatibility" before getting too deep. You're better off learning how to do that right, lest you be caught with your pants down later and have to re-create a bunch of services originally intended for .NET clients that now need Java clients (for smart phone apps, for example).
We made this mistake ourselves and ended up having to re-create a ton of web services when we started developing services that needed to be consumed by Android/Blackberry clients. Given the way the industry is trending more toward smartphone development, getting it right now will save you lots of work later on.