Prizes & Awards
My Profile
Active Members
TodayLast 7 Days
more...
|
Resources » Articles » .NET Framework »
Design patterns
|
Creational Patterns
Abstract Factory: Creates an instance of several families of classes
Builder: Separates object construction from its representation
Factory Method: Creates an instance of several derived classes
ProType: A fully initialized instance to be copied or cloned
Singleton: A class of which only a single instance can exist
Structural Patterns
Adapter: Match interfaces of different classes
Bridge: Separates an object’s interface from its implementation
Composite: A tree structure of simple and composite objects
Decorator: Add responsibilities to objects dynamically
Facade: A single class that represents an entire subsystem
Flyweight: A fine-grained instance used for efficient sharing
Proxy: An object representing another object
Behavioral Patterns
Chain of Responsibility: A way of passing a request between a chain of objects
Command: Encapsulate a command request as an object
Interpreter: A way to include language elements in a program
Iterator: Sequentially access the elements of a collection
Mediator: Defines simplified communication between classes
Memento: Capture and restore an object's internal state
Observer: A way of notifying change to a number of classes
State: Alter an object's behavior when its state changes
Strategy: Defer the exact steps of an algorithm to a subclass
Template Method: Encapsulates an algorithm inside a class
Visitor: Defines a new operation to a class without change
An example implementing the design patterns would be a Shopping cart application:
Brief explanation of the above:
Facade Pattern
The Facade design pattern plays a key role in the overall design of the application. The facade pattern not only enhances and simplifies the design of the application itself, but it also positions it be easily integrated into a larger Service Oriented Architecture (SOA). As you know SOA is hot and most companies are already taking their entire IT infrastructure in this direction. Business objects are invoked from the UI via this Facade.
When using a Facade the code-behind is often as simple as this:
ICustomerFacade facade = new CustomerFacade();
DataGridCustomers.DataSource = facade.GetCustomers();
DataGridCustomers.DataBind();
Composite Pattern
The menu is designed as an hierarchy with parent and child nodes. This self-referencing tree structure is implemented using the Composite design pattern.
Observer Pattern
Error logging and tracing are implemented with the help of the Observer pattern. Observer classes register themselves with the Logger and listen for Log events. In fact, two design patterns are at play here as the Logger class is a Singleton also.
Strategy Pattern
In the non-persistent e-commerce shopping cart, Items can be added, removed, and recalculated in the cart. The Strategy pattern is used to swap out different strategies for tax and insurance computations (and can easily be extended to included shipping charges, if necessary).
Abstract Factory + Singleton
The Abstract Factory pattern solves the problem of accessing different databases. Database specific factories are created which themselves are Singletons. These factories allow you to change databases simply by changing an entry in web.config. Two databases are included: one in Access and one in SQL Server.
Proxy Pattern
In this application each customer business object has a reference to a list of the orders that have been placed by the customer. However, not all situations require orders; for example when displaying a simple customer list. Only when the orders are truly needed are they loaded. This process of just-in-time loading is called Lazy Loading and is implemented by the Proxy object. Both Orders and Order Details are proxied.
Using patterns to build a robust 3-tier architecture
Many .NET applications today do not benefit from a robust 3-tier architecture. They are built on a simple 2-tier client/server model in which all code (UI, business logic, and data access) has been placed in one location: the code behind pages.
It is true that the initial development cycle may be shorter, but in the long run you'll find that these applications do not evolve easily with changing business needs. They are hard to maintain, nearly impossible to change, difficult to integrate (i.e. expose as a Web Services for example), and do not scale well (for when your website becomes an instant success!).
Of course, the question arises how you go about building a pattern-based, 3-tier application. Here is an overview of how its done in Patterns in Action!
In a 3-tier model each tier corresponds directly to one of the three elements needed in an architecture: interaction, manipulation, and storage. The three tiers or layers are:
Presentation layer — handles external interaction with the user
Business layer — manipulates the information required by the user
Database layer — stores the data handled by the system
The PL:
The concern of the presentation layer (PL) is to present information in a consistent and easy-to-understand manner to the end-user. As an ASP.NET web application developer you know the PL very well: it is the .aspx pages with associated code behind files.
From PL to BL: The PL calls into the business layer (BL) through a service-oriented interface which is an implementation of the facade design pattern. All data exchange between PL and BL uses the facade because this is normally where authorization and transactions are managed. In addition, if you wish to expose your application as a Web Service, then the facade will make this very easy for you (A demonstration of this is included).
The BL:
In the business layer (BL) behind the facade you'll find numerous business objects, such as, Product, Customer, and Order. Business objects encapsulate business logic in the form of business rules, but they have no knowledge about 1.) who is using them (UI, Web Service), or 2.) where their data is stored (i.e. its persistence).
From BL to DL: It is interesting to note that the business objects themselves do not interact with the data layer (DL). For example, you don't ask a Product business object to save itself -- there are no Save or Load methods on the business objects. Instead, persistence is handled by dedicated Data Access Objects (another Enterprise Pattern) that extract data from the business objects and subsequently store it in the database.
The DL:
The data layer (DL) implements a 'data provider factory' which exposes a database neutral interface. The benefit of this is that it allows the application to easily change to another database. The 'data provider factory' uses the abstract factory pattern and returns database specific singleton factories. A a great real-world example of how design patterns frequently work together.
Even if you do not purchase the Design Pattern Framework we'd like you to walk away with the following important observation:
Have you noticed that there are no direct interactions between the PL and the DL? In other words, the UI never calls directly into the data layer. This is by design. The reason is that security and transactions are usually managed in the business layer. You cannot bypass these important functions -- therefore, all communication with the database must go through the service facade in the BL
|
Responses
|
No responses found. Be the first to respond and make money from revenue sharing program.
|
|