I just got a question about an earlier post of mine, in which i describe how i use NHibernate in my WCF services. Here’s the question that i got:
My architecture at works requires a web app and a windows app to talk to the application server via WCF. The Application server being where all the Data access and Service libraries live. I intend to implement NHibernate into the project. But wanted to get some pointers if your approach above is recommended for Web and Windows clients alike when sending and receiving data via WCF?
The short answer to that question is simply: It sure as hell is!
But you know i always prefer the longer answer 
. The type of client always has an impact on the usage patterns of the service(s) that it needs. A web client will often have a different usage pattern than a windows client or a mobile client will. Each client should be able to consume the service in the manner that is most suitable to its requirements and constraints. A web client is (or should be) completely stateless so a service that is meant to be used by a web client is typically geared towards that stateless model. Windows clients or mobile clients are typically not entirely stateless and as such, the way they could use a service in the most optimal way often differs from how a web client would use the service.
One of the most important SOA principles is that there should be no implicit coupling between a service and its client(s) at all. Generally speaking, coarse-grained operations are favored over fine-grained ones due to the cost of the communication overhead. Yet, that easily conflicts with the usage patterns of different clients. Since a web client is stateless, it often needs more coarse grained operations than a windows client which can retain data in its own process memory and thus, might benefit more from calling a fine-grained operation here and there.
Obviously, my solution to that problem is Agatha which makes it possible to implement each operation (or call them actions or commands and queries or whatever else you can think of) in the way that just makes the most sense, no matter what kind of client is going to call them. Each client can consume the service operations in a manner that is optimal to the client, without the typical design impact and overhead that you have with traditional WCF services.
We have a few services that serve multiple types of clients. ASP.NET pages. Silverlight applications. Windows Services. WPF tools. Outlook add-ins. And guess what? Those services don’t have a clue as to who or what is using them and they are all implemented in the same way. And it hasn’t caused a single problem or difficult design decision (as to the service API) yet.