How to Architect an Application

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

In my experience I have seen the business requirements continuallly 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

For the last decade or 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 example, there might be one additional property you might want to add or change. For existing property characteristics you always need to do an impact analysis everywhere the dependency is created and it very hard to do that in very large projects.

If it is a small or medium-seized project then 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 the URL http://www.theserverside.net/news/thread.tss?thread_id=29914

If it is large sized project then prefer using modeling tools to model the data model. A 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

The Data Access Layer (DAL) is the separate layer whose responsibility is to handle the database operations. Data operations can be Create, Read, Update or Delete (CRUD) operations.

Now if you are wondering how to create the DAL layer then the following is the procedure:

• If you decided to use the ORM frameworks then they will generate the data objects based on your database objects. You don't need to write a 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 for creating the database objects and generate the DAL library. The 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. The Business Logic Layer (BLL), or sometimes people call it the Business Access Layer (BAL) is the layer where the application business logic exists. 

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

The answer is that there may be some decision to change your database that shouldn't affect your existing business logic. Rewriting or tweaking the data access logic should ensure it works for new database support. Data modeling tool will be used to do 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? The 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 (that has user interface), you will have the following 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 the future, the 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, 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 exception messages are logged or unhandled as exceptional conditions and so on in a common place.

Why it is needed?

If something is failing then say for example the record insertion or update is failing in the DAL or if some business logic fails in the BAL, how will you determine as a technical person how 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 as simple storage like a text file or to a 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 is it 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 a very high-level overview of the basic architectural view. You should be able to understand how important the layering is.

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