ASP.NET 3.5 Application Architecture and Design: Build robust, scalable ASP.NET applications quickly and easily.

There are many different definitions of software architecture scattered across the web, in reference materials, and in books. In the wide world of programming, many of the definitions you may find are most likely going to be extremely technical in the language they use, and can be difficult for a beginner to fully grasp and understand. There are even places on the web that list thousands and thousands of different definitions by leading software architects, engineers, doctors, philosophers, and professors. (Reference: http://www.sei.cmu.edu/architecture/community_definitions.html).

To begin with, let's start with a technical definition:

Now we will translate this definition into something simple, generic, and easy to understand:

Software architecture is a blueprint of your application.

To elaborate more on the "blueprint" part, let us try to understand software architecture with a simple analogy—the process of casting.

Casting is a manufacturing process in which a liquid material is poured into a mold that contains a hollow cavity of a desired shape. The liquid is then allowed to cool and solidify, taking the shape of the mold it was poured into. The mold is the guide that shapes the liquid into the intended result. Keep in mind that the mold can be of any shape, size, or dimension, and is separate or unrelated to the liquid that is poured in.

Now, think of software architecture as the mold and think of your project as the liquid that is poured into this mold. Just like casting, software architecture is the guide that shapes your project into the intended result. The architecture of a software system has no strict relation to the actual code that is written for this system. The architecture simply makes sure that the development process stays within certain defined limits.

Software design refers to the thought process involved in planning and providing for a better solution during problem solving. Software design comes after the architecture is decided upon. Architecture is more closely related to the business needs of the project, and theoretically it does not concern the actual technology platform (such as J2EE or Microsoft .NET or PHP) on which the application will be built (although practically we can decide the platform either in parallel with working on the architecture of the application or before doing so). Software design deals with the high-level concepts related to the actual implementation of the architecture in our projects, which include tasks such as usability studies to make sure our project targets the right kind of users, deciding which design patterns to use to make our application scalable, secure and robust. During the design phase, we also decide on the implementation methodology to be used in the actual development phase (which comes after design and involves actual coding). The following diagram shows how architecture and design fit together and relate to each other:

As we can see in the diagram, the actual business requirements and scope of the project are the deciding factors when working on the application architecture. Software design and development come next and, based on the design, the actual development work gets executed. A single problem can have many possible solutions, some of which will be more efficient than others. Before a developer starts chunking out code for a particular business requirement, it would be prudent and beneficial to give some thought and select the best approach from the possible list of options to assure that code performance, scalability and maintainability is not sacrificed in the long run.

In order to understand all of this by way of a simple analogy, consider a car manufacturing plant as an example. The mechanical engineers developing the high-level blueprint of the car would be the architects, and the blueprint itself would be the architecture of the car. This blueprint would include high-level specifications such as:

So the blueprint would specify the limitations as well as the conditions that need to be fulfilled for any design of that car, and besides the blueprint there would be additional constraints such as the budget for the production costs. But this blueprint would not include details of how exactly the engine would be designed, what quality of steel would be used, what type of tires would be used, what type of plastics would be used for the dashboard and other parts, and so on. All of this would actually be decided by the design engineers, who will make sure that their choices fit the blueprint specifications in the best possible way. The engineers will also consider production and design techniques that other car companies might have followed, so that they don't re-invent the wheel.

The actual assembly line production will follow the designs and techniques specified by the engineers and will involve tasks such as cutting metal, choosing the right machines, assembling the individual components, painting, safety tests, and so on, to create a complete working car. The following figure will correlate this example with the equivalent aspects of software development:

From the figure we can see how the car company example loosely translates to software architecture, design, and development. Now let us take another analogy, this time more closely related to the software industry. Consider a company that needs to build a bulk emailing program for its social networking website. A software architect will first understand the high-level requirements of the program, such as:

Based on the answers to the above questions, the architect will come up with an application architecture which covers all aspects of the actual business needs. The architecture will decide how the emailing program should be developed: a Windows Service, or a Web Service, or a console utility, or some batch program run by a scheduler.

But the architecture would not include details such as:

That's the part where design comes into the picture. The application architecture would define limits and boundaries within which the design would move around and improvise. So the architecture would neither go deep into the nitty-gritties of the design phase, nor would it dictate implementation guidelines and programming rules, as the architecture has no relation with programming at all. In fact, the architecture lays out specifications which are more aligned with business requirements, and makes sure that all business aspects are met and taken care of.

Coming back to our bulk email program, the term software design can be loosely translated into the process of designing the actual program, which involves using specific programming techniques (or design patterns, which we will study later) and laying out the basic solution framework. All coding would actually occur within that framework. We can have multiple design options for the same architectural specification, and it is up to the stakeholders to decide which one to go for, considering the overall efficiency and budget constraints.

Here is a simple diagram illustrating the basic process:

With time, some of the famous and widely used approaches and techniques among the architects have been grouped together into architectural styles. A particular architectural style represents the interaction and behavior pattern between the system and its components, along with a particular layout and structure. Some famous architectural styles are:

There are many more styles, and each style can be customized to suit individual project needs. We will learn more about some of these styles in the coming chapters, along with some practical examples. It is very important to understand the concept, approach, and effective implementation of a style so that we can decide when to use which style in our own applications. One can even create a new style by combining any of the existing styles and customizing it to achieve greater efficiency and adaptability.

The above quote (taken from No Silver Bullet—essence and accident in software Engineering, Brooks, F. P.) aptly highlights the fact that technological improvements can only be stepping stones instead of being silver bullets to solve all architectural and design problems in one go. The ASP.NET platform has rapidly gained a foothold in the web development industry. One of the major factors in favor of ASP.NET, compared to JAVA or PHP, is the excellent integration of the Microsoft IDE, Visual Studio, with the framework. The VS IDE has evolved, complementing the framework itself, with time-saving features such as detailed intelligence support, debugging assistant, and code complete, to list a few. Also, Microsoft has been aggressively adding different tools and technologies, enhancing the overall developer experience. AJAX, LINQ, WCF, WWF and SilverLight have not only stirred up the development world but have also left many developers confused and wondering as to how good these new technologies are, and how they can maximize their productivity by using them.

We have thousands of books, online articles and tutorials on how to use AJAX, LINQ, WWF, and WPF in ASP.NET, but there are still very few online articles and limited books that focus on what architecture to use, and in which ASP.NET application. Because each project is unique in its own way, we can never use a copy-paste solution. The important thing to bar in mind when learning application architecture and design is that there are no strict rules, only guidelines. And these guidelines were developed based on the experience gained over years of work by developers on different projects.

Upcoming latest technologies should not be mistaken as the means to develop better applications. Lets go back to the pre-ASP.NET years for a moment. In those days, classic ASP was very famous. There were many big, famous, and stable applications in classic ASP 3.0. It was difficult to create an object-oriented application with classic ASP (compared to the intuitive way, in which we can do it so easily now in ASP.NET), but good programmers used classes in ASP as well, adopting elements of object-oriented re-usable design. A better platform, such as ASP.NET, did help in building websites that could support a better architecture, but the power to use it in an efficient way still lies in the hands of an experienced programmer.

Just as ASP.NET was a major stepping stone in web development, AJAX enhanced the UI experience along the same lines, providing a user-friendly experience while browsing websites, and LINQ was introduced to revolutionize data access. But still there are numerous robust and popular websites in ASP.NET not using any of the new technologies. This means that the key to building a good website can never only be learning and absorbing the latest technology out there, but also how you put it to use—how you make these technologies work for your project in a comprehensive way.

If one knows how to write clean and maintainable code and use efficient programming techniques to create a good stable architectural platform and application structure, then technology will supplement the design. Without a stable architecture and good coding practices, a programmer might use the technologies in a haphazard manner, creating messy code and junk websites. But once we understand basics of the application architecture and the different design patterns, then these technology tools become our assets.

How do business requirements dictate architectural decisions? Lets understand this through a quick and small example. Assume that a software company, Takshila Inc., has recently bagged the contract for building a new inventory management system for a local cosmetics manufacturing firm. After the initial talks with the stakeholders, the business analyst from Takshila comes up with high-level specifications, which are:

With these requirements in mind, and after detailed discussions with team members, the software architect has come up with the following architectural specifications for the proposed inventory management software:

Note how the business requirements have been translated into architectural specifications, and still there is not a word about a programming or development platform! So the architecture has nothing to do with development platforms, programming languages, design and so on. We can create a system satisfying the above requirements in many ways, using different designs and probably using different platforms too (for example, one could either use ASP.NET or JSP/J2EE). In short, the architecture does not care whether you use LINQ, AJAX, or Ruby on Rails. As long as you are meeting the architectural specifications, you are free to choose your own technology and tools.

The word pattern means a guide or a model that is to be followed when making things. In software development, we often use programming techniques and solutions developed by others that prove to be credible over time. Solutions to software problems were not developed overnight, and most of these problems were common across the development world, so these time-tested solutions were grouped to be re-used by others.

So a design pattern is a re-usable solution that can be used in our projects so that time-tested programming techniques can be employed to solve similar kinds of problems.

The main difference between architecture and design patterns is that design patterns deal with implementation-level issues, and are more close to the programming and development platform, whereas architecture is at a more abstract level and is independent of the implementation. Design patterns tell us how we can achieve a solution in terms of implementation. But the patterns themselves are independent of the programming language and technology platform. We can implement a particular design pattern in any language we want: JAVA, C# or PHP. We cannot use design patterns as-it-is in our projects. They show us the right path to take in order to solve a problem, but they are not a complete solution. We cannot simply copy-paste a particular design pattern's code directly into our project. We will need to modify it to suit our own unique needs and implementation platform.

In the coming chapters, we will learn some of the famous design and commonly used patterns, with sample code in ASP.NET.

From an idea to a fully functional binary or DLL, a project passes through a varied range of activities and processes. The project life cycle refers to the different logical and physical stages that a project goes through from inception to completion. The life cycle starts with gathering the business requirements and ends when the final product is delivered after complete testing. The following are the major stages of a generic project life cycle:

These stages are more-or-less common through all projects. In this section, we will see some of the basic processes and understand the importance of each. Note that it is not necessary for each project to follow a standard life cycle strictly. Every project will have its own modified version of the life cycle, as well as its own duration for each stage.

There is a misunderstanding that tier and layers are two different names for the same entity. The concept of tier and layers came into being with the need for identifying and segregating different parts of an application into separate connected components. This separation can be at two levels:

Logical Separation

Separating into layers mean that we logically separate the code, but the entire application will be a part of a single physical assembly (or a set of assemblies depending on the compilation model). We may put the code files into separate folders, each having its own namespace for easier code management and readability, but we won't have a separate assembly for each different namespace or part of the code. Also, unlike physical separation, it will not be possible to deploy parts of the application in a distributed manner.

So a "tier" is a unit of deployment, while a "layer" is a logical separation of responsibility within the code. A layer becomes a tier if it can be physically separated from the layers consuming it. Alternatively, a tier is a layer which could be physically separated from the layers consuming it.

Note

If we are using the Visual Studio 2005 Website model, then we may have a set of assemblies for each page/folder, whereas if we use a Web Application Project (WAP) model (similar to the one used in VS 2003) we will have only a single assembly for the entire project.

Let's say we have a simple online guestbook system, which is a web-based application developed in ASP.NET. Here is a simple flowchart in a very basic form:

The user logs on to the website and visits the online guestbook, and clicks on the show all comments button. As a result, the system will show a list of comments to the user. For the same, the system sends a query to the Access DB, which in turn replies with a list of all the comments.

Now, one way to program this system is to create a simple web form with button, with the code to get the comments from the database placed inside the ASPX form (without using any code behind classes). The solution will compile into a single DLL. This inline coding approach will be discussed in the next chapter. Another method is to use code behind classes segregating the ASPX code and the C#/VB.NET code. We can introduce further loose coupling by separating the business logic and data access code into separate class library projects.

For a Windows-based project, also known as a thick-client, an n-tier project would have:

• Windows forms (or Windows Presentation Foundations, WPF) as the Presentation layer

• C# or VB.NET code handling the business logic as the Business Layer (BL)

• Data access code as the Data Access Layer (DAL)

• The physical database as the Data Layer (DL)

Data access layer (DAL) is a set of classes used to encapsulate data access methods like CRUD (Create Read Update and Delete) operations as well as any other methods accessing data from a data store (known as Data Layer). DAL's primary job is to communicate with the Data layer, which can be any RDBMS, set of XML files, text files, and so on. The DAL layer should act as a 'dumb layer' which is used directly by the BLL or any other service layer. The DAL layer should not contain any specific logic in its classes, and it should be used like a "utility" or "helper" class to fetch and store data to and from a data store.

Business logic layer (or the BLL) contains the business logic and set of operational rules particular to the application and talks to the data access layer (DAL) to:

• fetch data on which it has to apply rules

• save updated data after applying rules to it

• perform operations and validate data

BLL usually presents the data to the higher Layers (like a GUI layer) after performing business rules on it. This layer may also include error handling, logging, and exception handling strategies, besides encapsulating all the business rules of the project.

UI layer contains the graphical display components and files like ASPX, ASCX, MasterPages, stylesheets and so on. The UI layer usually is the Website or Web Project in the Visual Studio solution for ASP.NET projects.

Most developers confuse the data access code (DAL) as the data layer (DL). The data and data the access layer are different. DAL is the actual code that we use in our applications to connect to a database, and the database itself is actually the data layer (DL).

Here is a sample diagram of how the different layers act:

Now in the diagram, if we separate each of the code layers into its own project and class library, then we will have a 4-tier project: Presentation tier, BL tier, DAL tier and DL tier (the physical database).

But with web based applications, we have a built-in 3-tier architecture by default. The presentation tier is the client-side browser (instead of Windows forms), the code (assuming you have web forms, BL, and DAL in one assembly) is the Application tier, and the physical database is the Data tier.

If we break up the web project so that we have the business logic and data access code in one assembly, and the web forms/ascx controls and so on in another, we will have a 4-tier architecture. We can go on like this by breaking each component out into its own tier and introducing further loose coupling. We will see more on how to introduce loose coupling in our projects in the later chapters of this book. For the rest of the book, we will be focusing only on thin-client based architectures, that is, web applications in ASP.NET.

We will now see what options we have for how we can break the code into different tier and layers in any Visual Studio web project, and thus define a few models. Here I am assuming that we are breaking the main application into tiers, and not focusing on the database and the presentation (browser) tiers.

In this chapter, we learnt the definitions of architecture and design, how they are different from each other and where they fit into our projects. It is very important to understand the different stages of a project life cycle so that we can manage our projects better and mitigate risks early. We also examined the difference between tiers and layers and the different ways we can structure our project using tiers and/or layers. In the coming chapters, we will go deeper into n-tier projects and, with sample applications and code, we will understand the advantages and disadvantages of each option.