I\'m starting the design of a new app that is primarily network oriented, and I\'m looking for some advice from people who have come up with a good architectural design, or OOP
I am on the tail end of a client-server app that I started writing a few weeks ago. I used WCF for the .Net cient & server.
But the server also had to connect to a device on the network that only understood ASCII over TCP/IP.
Did you abstract out the communication bits?
Yes. I guess. I mean, I am not sure I understand your question 100%. For my TCP connection to the 3rd party device I hid the details of the TCP connection and communication behind a class I wrote. The device in question converts ASCII commands to IR signals to control things like satellite dishes and DVD players. I abstracted the TCP communication into a class so all my server had to do is make a call like:
_irService.SendCommand(someAsciiCommand);
What class entities did you come up with?
They were based on my domain. Yours should be based on whatever your domain is. I am not sure I understand that question beyond that. Your domain is going to dictate your objects.
In my domain I was dealing with a server application that was in charge of scheduling and playing multicast broadcasts over UDP utilizing VLC. These multicast broadcasts had to be configurable in every aspect.
When I analyzed the domain I came up with a model that consisted of Broadcasts, Channels, Devices and BroadcastProcesses (a class that was in charge of starting a vlc.exe process and maintaining its lifecycle).
The domain had little impact on the networking technology. I ended up with a few duplex "services" in WCF that allowed me to manipulate the domain. But the networking choices were not dictated by the domain. I wanted a TCP connection with binary serialization of my objects, and I wanted a two-way communication with the server so my clients could get real-time updates via callbacks. Those options were available to me regardless of what my domain looked like.
"Network application" is an unclear category covering quite a broad spectrum of possible requirements and designs. By definition, you will have to deal with concurrency and latencies. Robustness is always a challenge: it is all too easy to design a system whose availability is the lowest common denominator of all its hardware and software components. You will have to upgrade the O/S and components of your application: can you live with taking down all of the solution, or do you need some hot/cold standby or even failover capability? Networks fail in exotic ways (at least to us poor pure software guys): you are dependent on so many things you never consider (routers, switches, DNS servers, the temper of that bearded network engineer down the hallway!), and should design the interactions with a pessimistic frame of mind.
One warning: don't be too object-oriented when designing distributed applications. Objects have their place in managing software complexity, but the moment you start pushing them on the wire, a huge number of performance and version dependency problems raise their ugly heads. Service oriented architecture is a buzzword, but is useful as a design principle, to a point. The mainframe guys have known this for ages...
Two general book recommendations: