Summary

This chapter tackled some essential theory. Like any developer, you'd probably like nothing more than to plunge into distributed application coding and start mastering .NET Remoting, XML Web services, and threading right away. However, it's keenly important that you understand the basic premise behind distributed applications before you start programming. That basic premise is this: Distributed architecture relies on executing portions of code on different computers, not just on the client. This code is wrapped up into a neat object, or component, as described in Chapter 2.

Of course, now that you've followed the evolution of application architecture, it should be obvious why we need distributed applications. Without them, it's extremely difficult to expose processing logic to a massive audience (eager e-commerce shoppers, for instance). For large-scale systems, distributed architecture ensures scalability, reliability, and flexibility for future design changes. It can also help software bridge the gap between modern-day applications and legacy systems.

There's one secret that programming authors don't want you to know: Although .NET makes distributed programming a good deal easier, distributed design still adds complexity, and it's not always the best solution, particularly for small-scale systems. If you're creating an internal system that doesn't need to use distributed architecture, you can still benefit a great deal from this book. Incorporating tricks such as multithreading, disconnected data, and stateless design can still improve your code and make it easier to remodel as a distributed application if the need arises in the future.