I'm building a WinForms application where I'll need it to work "locally" (just like Microsoft Word, saving and opening files from the file system) and also in a multi-user environment (communicating with a server in the network, via TCP/IP).
In terms of architecture I'm thinking of these logical layers:
- Presentation (windows forms)
- Service
- Data Access
My plan is to make the "Service" layer a WCF service. So when the application is working in "local" mode, I'd host the WCF service in the Presentation (executable) process. Presentation would be a service host AND a client at the same time. It would access the service layer using a WCF proxy, pointing to "localhost".
When the application is in a network environment, I'd like to host the same WCF service in a "Windows/NT Service" process in some other machine, and Presentation would communicate with it using the same WCF proxy as in local mode.
That is, for Presentation I would have one API only.
In theory this looks good. However, I would like to know your opinion about this whole thing. Is it a bad practice to use WCF in this way, having server and client in the same process? Can you see an alternative/better way of doing this?
Another (maybe unrelated) question is: can I host and consume a WCF service in the same Windows Forms executable if I'm tagetting the .NET Framework Client Profile installation?
I appreciate your comments :)
I would say it's not bad practice at all to host server and client in the same process - it's called inter-process communication! :-)
For the local scenario, I'd use the NetNamedPipe binding - fast as hell, for "on-machine" communication only.
For the LAN scenario, just switch to NetTcpBinding - very fast and efficient as well.
Should work like a charm.
According to this page on the .NET Framework Client Profile, pretty much all of WCF should be supported on the client profile:
Marc