How to architect an Application

Many of us are developing web application and maintaining them as part of the daily routine. But most of them still struggle to maintain the web application due to lack of flexibility and separation of the concern.

In my experience I have seen the business requirements keep changing based on the business priorities and the application should support the changing business needs.

Now, let's get into the business of how to architect an application

1. Deciding the right modeling tool

From last decade or so, so many tools and frameworks are created to address the database requirements. Most of them are like reverse engineering, where you create the database schema and objects and then build application logic on top of it.

Because of rapid changes in business requirements, it is very difficult to maintain the database changes. For ex, there might be one additional property you might want to add or change existing property characteristics you always have to do impact analysis on all the places where the dependency is created and it very hard to do in very big projects.

If it is a small or medium-seized project, prefer creating the database and object by hand and then use the ORM frameworks to generate the business objects to use them in your application logic.

For the list of ORM tools visit this url http://www.theserverside.net/news/thread.tss?thread_id=29914

If it is large sized project, prefer using modeling tools to model the data model. Good thing about the data modeling tools are that the objects are integrated and easy to maintain.

Some of the modeling tools are Microsoft Entity Framework and Deklarit. You can visit their home page to get more information.

2. Layering the DAL

DAL (Data Access Layer) is the separate layer whose responsibility is to handle the database operations. Data operations can be CRUD (creation, read, update or update.) operations.

Now if you are wondering how to create the DAL layer, here you go.

• If you are decided to use the ORM frameworks, they will generate the data objects based on your database objects. You don't have to write single line of code to create and maintain the data access library.
• If you have decided the data modeling tool, then the data modeling tool will be responsible to create the database objects and generate the DAL library. Same DAL library can be used to do the CRUD operations.

3. Layering BLL

Now we come to the important piece of the business logic. BLL (Business Logic Layer or sometime people call it as BAL) is the layer where the application business logic will be present. 

Why do I really bother about separating the business layer from data access layer?

Answer is that there may be some decision to change your database and that shouldn't affect your written business logic. Rewriting or tweaking the data access logic should make sure it works for new database support. Data modeling tool will be used to achieve with less effort.

Similarly, if the business logic changes that shouldn't affect the written data access logic. Keeping them separate and independent will be maintainable for long term.

4. Presentation Layer

Since we created the foundation of creating the DAL and BLL, any type of application can be built on top of it. Is there specific attention required for types of applications? Answer is yes and no. It really depends on the business requirement. Since we are dealing how to architect an application but not what type of application we can leave it here.

Now assume you are creating any type of interactive application (which has user interface), you will have the below characteristics:

1. User interface
2. Presentation logic that handles the UI events
3. Some workflow to process your input and return the output.

Now because we have 3 concerns the UI, application processing logic and the workflow, all three should be separated. Because in future, UI can be changed from time to time. So the code you will write to handle the presentation and calling the workflow to process the request should be separated to handle the smooth transition of changing the UI.

 

5. Logging

Now as the application is layered and built, now you need to have the essential tools to support the maintainability of the application. Logging is one among them. 

So what is Logging? 

Logging is a mechanism through which log your exception messages or unhandled exceptional conditions etc in a common place.

Why it is needed?

If something is failing, say for example the record insertion or updating is failing in the DAL or if there is some business logic fails in the BAL how will you come to know as a technical person to fix the problem.

How do I log the message?

You can use simple frameworks like Log4Net or Elmah to do that. Logging the messages can be stored from simple storage like text file to the secure storage like database. Some of the logging framework supports logging the message and send email on the same.

6. Auditing

Another piece of tool for data maintainability is the auditing.

What is auditing?

Auditing is a process or mechanism to record the data changes happened on a given record.

Why it is needed?

Storing the business records in the database is part of the technical requirements. But tomorrow if you want to know what values are changed and by whom is very important information to support the argument.

How to I do the auditing?

Auditing can be either done from the application layer or from the database level.

Conclusion

So now, I gave very high-level of basic architecture view you should be able to understand how important is the layering is.

I will address architecting the specific type of applications in my next articles.