One approach to designing Web applications is to focus on clearly defined layers of the application's architecture. This approach is similar to the way an architect designs a building. If you've ever seen detailed construction plans for a skyscraper, you know the construction plans include separate blueprints for the foundation, frame, roof, plumbing, electrical, and other floors of the building.
With a layered architecture, specialists can design and develop the "floors" — called layers — independently, provided that the connections between the layers (the interfaces) are carefully thought out.
The layers should be independent of one another, as much as possible. Among other things, that means heeding a few must-dos and shalt-nots:
- Each layer must have a clearly defined focus. To design the layers properly, you must clearly spell out the tasks and responsibilities of each layer.
- Layers should mind their own business. If one layer is responsible for user interaction, only that layer is allowed to communicate with the user. Other layers that need to get information from the user must do so through the User Interface Layer.
- Clearly defined protocols must be set up for the layers to interact with one another. Interaction between the layers occurs only through these protocols.
Note that the layers are not tied directly to any particular application. For example, an architecture might work equally well for an online ordering system and for an online forum. As a result, layered architecture has nothing to do with the ERDs that define a database or the Data Flow Diagrams that define how the data flows within the application. It's a separate structure.
How many layers?
There are several common approaches to application architecture that vary depending on the number of layers used. One common scheme is to break the application into two layers:
- Application Layer: The design of the user interface and the implementation of business policies are handled in this layer. This layer may also handle transaction logic — the code that groups database updates into transactions and ensures that all updates within a transaction are made consistently.
- Data Access Layer: The underlying database engine that supports the application. This layer is responsible for maintaining the integrity of the database. Some or all the transaction logic may be implemented in this layer.
In the two-layer model, the Application Layer is the ASP.NET Web pages that define the pages presented to the user as well as the code-behind files that implement the application's logic. The Data Access Layer is the database server that manages the database, such as Microsoft SQL Server or Oracle.
Note that ASP.NET 2.0 doesn't require that you place the application's logic code in a separate code-behind file. Instead, you can intersperse the logic code with the presentation code in the same file. However, it's almost always a good idea to use separate code-behind files to separate the application's logic from its presentation code. All of the applications presented in this book use separate code-behind files.
The division between the Application and Data Access layers isn't always as clear-cut as it could be. For performance reasons, transaction logic is often shifted to the database server (in the form of stored procedures), and business rules are often implemented on the database server with constraints and triggers. Thus, the database server often handles some of the application logic.
If this messiness bothers you, you can use a three-layer architecture, which adds an additional layer to handle business rules and policies:
- Presentation Layer: This layer handles the user interface.
- Business Rules Layer: This layer handles the application's business rules and policies. For example, if a sales application grants discounts to certain users, the discount policy is implemented in this layer.
- Data Access Layer: The underlying database model that supports the application.
Creating a separate layer for business rules enables you to separate the rules from the database design and the presentation logic. Business rules are subject to change. By placing them in a separate layer, you have an easier task of changing them later than if they're incorporated into the user interface or database design.
Model-View-Controller
Another common model for designing Web applications is called Model-View-Controller (MVC). In this architecture, the application is broken into three parts:
- Model: The model is, in effect, the application's business layer. It usually consists of objects that represent the business entities that make up the application, such as customers and products.
- View: The view is the application's user interface. In a Web application, this consists of one or more HTML pages that define the look and feel of the application.
- Controller: The controller manages the events processed by the application. The events are usually generated by user-interface actions, such as the user clicking a button or selecting an item from a drop-down list.
In a typical ASP.NET application, the .aspx file implements the view; the model and controller functions are combined and handled by the code-behind file. Thus, the code-behind file can be thought of as the model-controller.
You can, of course, separate the model and controller functions by creating separate classes for the business entities. For simplicity, the applications in this book keep the model and controller functions combined in the code-behind file.
dummies
Source:http://www.dummies.com/how-to/content/using-layered-architectures-in-aspnet.html
No comments:
Post a Comment