Designing Framework Applications: Using Design Patterns with VS.NET Framework Applications
- Defining Patterns and Architecture
- Patterns Drilldown
- Architecture
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Even with a modern and robust development tool such as Visual Studio .NET, developing software is an inherently difficult task. Developers need all the help they can get and should seek out that help whenever and wherever they can. Fortunately, the object-oriented nature of the Windows .NET framework and the popularity of VS .NET mean that developers have many avenues for piggybacking on the thinking and work of others (the extensive information here in the .NET Reference Center is a primary example).
In this article, however, I want to focus on two broad aspects of software design and implementation, patterns and architecture, to give you some resources you can use when building great framework applications.
Defining Patterns and Architecture
I'll begin by defining what I mean by "patterns" and "architecture." As used in this article, patterns are typically what developers think of as design patterns. Simply put, design patterns are "simple and elegant solutions in object-oriented software design" (as defined by the book Design Patterns: Elements of Reusable Object-Oriented Software, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, collectively referred to as the Gang of Four, or GoF [Addison Wesley Professional, 1994]). As a result, patterns address lower-level issues that often arise when designing classes for use in applications. And because framework applications are composed of classes that utilize the object-oriented infrastructure provided by the Common Language Runtime, they are well suited for use by VS .NET developers.
I refer to these patterns as micro patterns, patterns used individually or in combination by developers to design flexible, reusable, and elegant solutions in their software. Design patterns are also evident in the design and implementation of the framework itself.
Patterns, then, are contrasted with architecture. Architecture can be thought of as a collection of decisions that define how various parts of a solution interact. For this reason, architecture consists of macro patterns, or architectural patterns that might include both framework and custom software built using lower-level design patterns. For example, many modern applications are based on the central architectural pattern referred to variously as multitier, three-tier, or layered. In this construct, the application is roughly split into three layers: presentation, business (or domain), and data. Each layer presents a well-defined boundary within which various micro patterns can be employed. I've chosen to use the terms layered and layers rather than tiered and tier because tier often connotes physical separation, which need not be (and often is not) the case.
For another general introduction to patterns and architecture, I recommend the Webcast "Using Patterns to Build Business Applications," by Microsoft Architect David Trowbridge.