Application Architecture
Introduction:
Application Architecture is the
most important process of developing a good application. Some people tends to
jump into coding without any architecture laid. Later we see those people
changing the architecture and finally the application had to be developed from
the scratch with the correct architecture.
In this article I will describe
some details about how you can improve the architecture of you application. This
article is targeted to the beginner's audience.
Three layered approach:
Three layered approach is the most
common approach taken to build a web application. In this approach application
is divided into three layers.
1) Database layer:
The database layer contains the
tables, views and stored procedures which deals with the database. Usually this
layer is created before making the other layers. Database layer is also the most
important layer in the application architecture that's why most of the time is
spent making the database layer solid so, the pillars of the application are
strong and scalable.
2) Business logic layer:
Business logic layer contains the
logic of the application. Like the database layer this layer is not exposed to
the users directly but a user interface is provided to do so.
3) Presentation layer:
The presentation layer is what the
user actually sees. The html pages with some animation, the textboxes to take
input and message boxes to alarm the user of the operation of his action.
Presentation layer must be developed in such a way that it can be changed
without doing any changes to the business or the database layer. This means that
the presentation layer must be independent of the database and the business
layers. Also the presentation layer should be made in such a way that changing
the presentation to the user will take less time and effort.
Tips about the database
layer:
1) Database layer as I pointed out
earlier consists of a database, stored procedures and tables etc. Its always
good to use stored procedures instead of Ad-Hoc queries. Ad-Hoc queries have the
danger of SQL injections. Stored procedures on the other hand are more fast to
execute and gives the performance boost. Since those procedures used often are
executed from the cache.
2) It's very important that you
normalize the database design. You should carefully map out the one-one,
one-many, many-many relationships. If normalization of the database is not
handled carefully at the right time it can destroy the whole application and you
may have to start from scratch.
Tips about the Business
layer:
Business layer is where all the
cool stuff happens. Usually for each subject (noun) in our specification we make
a class for it. Suppose we are making an application where users and sends
emails and receive messages depending on if their email is sent or not.
Some users tends to keep all the
business logic in the presentation layer. This approach is very dangerous since
user has a direct interaction with the business logic and it becomes easily
hackable. That's why business logic is always kept in the class libraries this
approach makes the separation of the user interaction with business logic and
also makes the libraries portable so, it can be used by some other same type of
application.
Sometimes its also a good idea to
map the class fields to the database column names. Suppose our application
stored articles so, our mapping class will look something like this:
|
public
class
ArticleDetails
{
public string
Title;
public string Url;
public string
Description;
}
|
The advantage of using this
approach is that if you make changes in the Title, Url, Description than you
will only need to send the object of the ArticleDetails class. This is also a
good approach since if later you decide to add one field to your database due to
bad design you can just add the same field to this class without having to play
around with the business logic methods.
Data Access Application
Block:
I also explicitly use
Microsoft.NET Data Access Application Block. Application Blocks makes the code
simpler to understand and modify. Another good reason to use the application
block is that it makes the code more readable if many coders are using the same
block instead you find yourself reading every line of code written by the
developer and trying to understand his coding style of accessing the database.
Messages Class:
Just like the Data Access
Application Block every frequently used operation should be converted into a
class for easier access. This includes Cache Block, Exception Handling Block
etc. I will talk about the Messages class whose purpose is to alarm the user
with a message about the operation that he has performed.
Sometimes you want to print a
message "Data has been successfully entered" if the transaction was successful
and "Data not entered" when, the transaction was a failure.
Most of the developers perform
this task by simply adding the if-else block in the presentation layer.
|
bool
isDataInserted = code.AddCodeSample(txtTitle,txtDescription);
if(isDataInserted)
{
// Data inserted
successfully
}
else
{
// Data not inserted
}
|
This is a common approach used by
developers to alarm the user of his operation. The problem with this approach is
we are repeating code, meaning that each of the event that is inserted, deleted,
updated, selecting, editing will have the same kind operation with a different
message and we will be writing same 4-5 lines everywhere. Hence, its a good idea
to make a class whose main purpose is to return messages. You can call this
class DBMessages.
|
// message returned after the insert operation
public static
string InsertMessages(bool
isAdded)
{
if(isAdded)
{
return
"Inserted";
}
else
{
return
"Not Inserted";
}
}
// message returned
after the Update Operation
public static
string UpdateMessages(bool
isUpdated)
{
if(isUpdated)
{
return
"Updated";
}
else
{
return
"Not Updated";
}
}
|
As you see now you only have to
write a single line of code to get the message. Here lblMessage is a label
control.
lblMessage.Text = DBMessages.InsertMessages(isAdded);
Using this approach you can also
modify your message in one place and it will be changed everywhere.
Tips for the Presentation
Layer:
Presentation layer design should
always be consistent since this layer will be the one that will change often.
Consistent design can come in the form of the Cascading Style Sheets and User
Controls. By using Cascading Style Sheets your page has a consistent look and
feel. A simple change in the Cascading Style Sheet will bring changes to all the
pages without even touching them.
User controls is another way for
making sections that are easily changed. If on the other hand if they are not
marked as a user controls we will have to go to each page and manually change
it which, is a pain.
Conclusion:
If the architecture of the
application is made correct. The rest of the coding (Implementation Phase)
becomes really easy.
I hope you liked the article Happy
Coding !