Introduction:
As a developer, the .NET framework and Visual Studio present many choices for
choosing the right architecture, from placing the data access code directly in
the UI through datasets and data source controls, to creating a data access
layer that talks to the database, all the way to creating an architecture that
consists of multiple layers, and use data-transfer objects to pass data back and
forth.
What is a Layer?
A layer is a reusable portion of code that performs a specific function. In the
.NET environment, a layer is usually setup as a project that represents this
specific function. This specific layer is in charge of working with other layers
to perform some specific goal. In an application where the presentation layer
needs to extract information from a backend database, the presentation would
utilize a series of layers to retrieve the data, rather than having the database
calls embedded directly within itself.
Traditional Architecture
When the .NET 2.0 framework became available to the world, there were some neat
features that allowed the developer to connect the framework's GUI controls
directly to the database. This approach is very handy when rapidly developing
applications. However, it's not always favorable to embed all of the business
logic and data access code directly in the web site, for several reasons:
- Putting all of the code in the web site
(business logic and data access) can make the application harder to maintain
and understand.
- Reusing database queries in the
presentation layer often isn't done, because of the typical data source
control setup in the ASP.NET framework.
- Relying on the data source controls can
make debugging more difficult, often due to vague error messages.
So in looking for an alternative, we can
separate the data access code and business logic into separate "layers", as
shown in the following figure
Presentation Layer
The ASP.NET web site or windows forms application (the UI for the project) is
called the presentation layer. The presentation layer is the most important
layer simply because it's the one that everyone sees and uses. Even with a well
structured business and data layer, if the presentation layer is designed
poorly, this gives the users a poor view of the system.
It's best to remove as much business logic out of the UI and into the business
layer. This usually involves more code, but in my mind, the excess time (which
ranges from minimal to moderate, depending on the size of the application) pays
off in the end.
Business Access Layer
Though a web site could talk to the data access layer directly, it usually goes
through another layer called the business layer. The business layer is vital in
that it validates the input conditions before calling a method from the data
layer. This ensures the data input is correct before proceeding, and can often
ensure that the outputs are correct as well. This validation of input is called
business rules, meaning the rules that the business layer uses to make
"judgments" about the data.
However, business rules don't only apply to data validation; these rules apply
to any calculations or any other action that takes place in the business layer.
Normally, it's best to put as much logic as possible in the business layer,
which makes this logic reusable across applications.
Data Access Layer
The key component to most applications is the data. The data has to be served to
the presentation layer somehow. The data layer is a separate component, whose
sole purpose is to serve up the data from the database and return it to the
caller. Through this approach, data can be logically reused, meaning that a
portion of an application reusing the same query can make a call to one data
layer method, instead of embedding the query multiple times. This is generally
more maintainable.
Conclusion:
We can develop very flexible system by following the architecture discuss above.