.NET Developer Tip
(Receive this column in your inbox,
click Edit your Profile to subscribe.)
Patterns and architecture defined for .NET
Dan Fox
To come up with a great design of an application or Web service using the .NET framework, it's a good idea to make sure you're familiar with the terms that are used. This tip, which is excerpted from InformIT, defines two terms that are in common usage, 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 com
To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
bination 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.
To read the entire article from which this tip comes, click over to InformIT. You have to register there, but the registration is free.
For More Information:
