Hello
Get into the Design Pattern World based developments
When developers hear the term "design pattern," they generally
envision one of two scenarios. One group of developers assumes you're
talking about lots of brainstorming and meetings without much real
coding being done. The other group has visions of proper planning to
ensure successful development and reuse of code.
The reality, as always, lies somewhere in between. Architects and
system designers should look for repeatable patterns when designing
solutions for their companies. But patterns should serve as guidelines
for developing robust, reusable code. Architects have to resist the
desire to overarchitect a solution at the expense of the most important
application feature: delivery.
Among the prime victims of overarchitecting are Web applications. Since
most Web applications are used to browse data, they should be
architected to favor speed of display over speed of data update. In
many cases, building a complex, multilayer architecture does not serve
the needs of users or developers. Let's look at a simple pattern for
developing .NET Web applications.
Implementing a classic design pattern using ASP.NET
Smalltalk, one of the earliest object-oriented languages, gave
developers a platform to develop best practices for object-oriented
systems. The classic Model, View, Controller (MVC) design pattern was
developed from this research and is still used today as a reference.
The Model holds the data displayed by the View and managed by the
Controller. The View is responsible for delivering output to the user,
and the Controller reacts to user actions and updates the Model
appropriately.
ASP.NET provides a perfect analogy for implementing this classic design
pattern. The data set contains the application data and represents the
Model component. A developer implements the View by developing the user
interface in the ASPX page. The Controller functions are implemented in
the code-behind file (Foo.aspx.vb or Foo.aspx.cs).
Implementing this design on .NET provides a two-tier system with
significant advantages over classic ASP architecture. Separating user
display (View) from actions (Controller) promotes code reuse.
Separating the data (Model) from the actions performed on it
(Controller) allows you to design a system independent of which back
end happens to be used to store the data. If designed correctly, a
system based on the MVC design pattern will neither know nor care
whether the data provided to the Model component was stored in a SQL
Server or Oracle database or a set of XML documents.
Many argue that developers can easily implement this pattern using ASP
pages and COM objects. But the reality is that most systems I have
audited either did not use COM objects or pushed only database access
to the COM objects; they still did all their business logic in scripts
on the ASP pages. I'm not saying that the MVC pattern advocates that
scripting should be removed from ASP pages. I am saying that scripting
in ASP pages should be limited to what is necessary to support the View
functions and not Controller functions.
Performance and extensibility
When architecting a solution based on this pattern, be sure to consider
two other issues. First, how well does the solution perform and how can
I increase performance? Second, how extensible and scalable is the
solution and where does it make sense to extend or break the pattern?
Performance
Although access to the Model from the Controller and the View should be
database-independent, that does not mean the Model itself can't be
optimized. Since the ADO DataSet does not care about the data source,
performance is improved without breaking the pattern by taking
advantage of database-specific features. For example, rather than using
SQL Select statements embedded in your code-behind file (Controller),
build stored procedures that return expected values given specific
parameters. Stored procedures are not only precompiled by the database,
but they also have a predetermined execution path that makes them very
fast and efficient.
You'll break the model, however, if you use stored procedures to
process business rules. These rules belong in the Controller, allowing
multiple views to take advantage of them. As a general rule, you should
use database-specific features to optimize performance or to enforce
referential integrity, but not to implement Controller features.
Extensibility and scalability
To scale successfully, an MVC-pattern application has to work in a Web
farm. As long as you design your application to either be stateless or
to maintain state between the View and the user (the default for
ASP.NET applications), you can then scale an MVC-based application by
simply replicating the ASPX pages and code-behind files to multiple IIS
Servers in a server farm, all pointing to the same database server.
When implementing this pattern, I've found that it almost always
makes sense to separate the logical Controller layer into two physical
layers. Rather than having the same data access code replicated across
multiple methods in the Controller layer, I prefer to consolidate all
the code in a single data access object that performs all data access
for the application. This data access object can be used by the
code-behind files from multiple applications. Microsoft provides a
great example of a consolidated data access layer in its data access
application block, which you can download from MSDN. Centralizing data
access code promotes code reuse, but more importantly, it allows you to
guarantee that your application takes advantage of connection pooling
by ensuring that connections are set up to take advantage of the
capability.
Better software, faster
Using design patterns helps you to build more reliable and supportable
software. When architecting systems for your customers, you should
consider building applications based on known patterns first and then
extending them based on specific application needs or performance
demands.
Reference
www.builderau.com.au/architect/sdi/soa/ ASP_NET_MVC_design_pattern/0,39024602,20268200,00.htm
|
No responses found. Be the first to respond and make money from revenue sharing program.
|