In last two posts, I have been talking about the layered architecture in ASP.NET applications. If you missed them, you might want to read the first part and the second part, just to get a better insight on the topic I am discussing today.
Dividing an application into multiple layers helps to:
- Keep different concerns of components separate so that there is clear distinction between different parts e.g. keeping presentation and business logic separate rather than making a mess by mixing them up
- Easy maintenance of the application
- Enhanced clarity of the application making it easy to understand
- Keep individual components cohesive and often efficient
- Loose coupling between layers
- Increase reusability, of course
In the layered approach, what we have noticed so far is that an application is best divided into the presentation layer, the business logic layer and the data access layer. Each layer can further be divided making it an n-tier application, but mostly the basic architecture revolves around the above mentioned three layers. With large applications, you may also choose to create a separate class library for each of these layers. However, with service oriented architecture, things have changed a bit. The service oriented architecture has become very popular today since for applications that need to interact with external system, services are the best solution. If you are not familiar with service oriented architecture, you can refer this article on Windows Communication Foundation to get an insight. Using services, applications can expose themselves to third party applications or the external world the way they want to. This helps in sharing of data, enabling remote access in secure way and makes the application very extensible.
If services are to be used, additional responsibilities can be added by using an extra layer called “service interface” to the required layers. The architecture will somewhat look like below, but again variations are the way.
The diagram is self-explanatory, and I will keep the detailed discussion on this for later. Today, I only want to bring to your attention that there is no standard way about how to design an application, Depending on the requirement of the application, the development environment, the target environment and many other factors, you have multiple choices with architecture. Different solutions are best solutions for different situations. However, over a period of time as the software industry has evolved, there have been some standard solutions that are known to be best suited for certain scenarios. Such solutions or ideas that have evolved with time and provide you simple solutions to complex situations are known as “design patterns”. Microsoft themselves have a series of articles written on suggested patterns and practices they want to share with us when it comes to developing applications in Microsoft technologies. They focus much on the three tiered approach and service interface if required, something that I have briefly talked about above.
In articles to follow, I will talk about more on this topic, mainly on things like Model-View-Controller architecture that Microsoft is so crazy about. This is not a new concept; in fact if you read Erich Gamma and the team’s book Design Patterns: Elements of Reusable Object-Oriented Software, the first chapter talks about MVC and SmallTalk. But MVC has stood the test of time that made Microsoft go gaga over it today. MVC is based on the Observer Pattern, one of the most popular design patterns, that also forms the base of Java. There are concepts like Page Controller and Broker, and then there are concepts like Service Interface and Service Pattern. I will be adding more discussions on architecture in this blog. Stay around!
0 comments:
Post a Comment