3-tire architecture using c# and asp.net
In the pure 3-tier / N-tier model, the application is divided into three formal tiers: the presentation tier (or GUI layer), the middle tier (or application server) and the data tier. Figure 2 shows a 3-Tier / N-Tier architecture. The key addition in this model is an application server which encapsulates the application's business logic . N-tier is used to describe this architecture since the application server may be implemented in one or more layers and it may be distributed in one or more places. For simplicity, the architecture will simply be referred to as "3-Tier", rather than N-Tier.
Presentation Tier
The presentation tier can include a variety of clients including standard clients (as part of a client/server application), Internet clients and reporting tools. Because business logic is implemented in the middle tier, there is relatively little duplicated effort should there be a need to provide the same function in two or more environments. For example, an Order details screen might be provided in both a client/server application and the Internet application while any business logic in the middle tier (application server) would be shared.
The presentation tier requests services from the application server but it is not limited to GUI clients. Items in the "top" tier might also include other applications that need to exchange information or data with this application.
Middle Tier (Application Server)
As mentioned earlier, the middle tier or application server might be implemented as several layers. Application servers can also be distributed on several host machines. A Transaction Processing (TP) monitor or an Object Request Broker (ORB) can be used to balance client requests across multiple database servers as well as start up/shutdown additional application server instances, as needed. Since the application server contains the business logic (where the bulk of the complex processing should occur), it is possible to support more users by adding more and faster application servers without needing to re-architect or rebuild the application.
It is not necessary to physically locate the middle tier on its own server from the beginning. In an early application release (which has a limited number of users), the middle tier might be deployed on the client machine or on the database server for simplicity. When the number of users grow (e.g. for later releases), the middle tier can then be moved onto separate server(s) so that the desired scalability benefits are obtained.
Data Tier
The data tier contains the database. It might also include data access procedures. The database can be placed in a single location or it can be distributed, if required.
The benefits of the 3-tier model are as follows:
Scalability: The key 3-tier benefit is improved scalability since the application servers can be deployed on many machines. Also, the database no longer requires a connection from every client -- it only requires connections from a smaller number of application servers. In addition, TP monitors or ORBs can be used to balance loads and dynamically manage the number of application server(s) available.
Better Re-use: The same logic can be initiated from many clients or applications. If an object standard like COM/DCOM or CORBA is employed (as discussed in tool dependence), then the specific language implementation of the middle tier can be made transparent.
Improved Data Integrity: since all updates go through the middle tier, the middle tier can ensure that only valid data is allowed to be updated in the database and the risk of a rogue client application corrupting data is removed.
Improved Security: Security is improved since it can be implemented at multiple levels (not just the database). Security can be granted on a service-by-service basis. Since the client does not have direct access to the database, it is more difficult for a client to obtain unauthorized data. Business logic is generally more secure since it is placed on a more secure central server.
Reduced Distribution: Changes to business logic only need to be updated on the application servers and do not have to be distributed to all the clients.
Improved Availability: mission-critical applications can make use of redundant application servers and redundant database servers. With redundant servers, it is possible to architect an application so that it can recover from network or server failures.
Hidden Database Structure: since the actual structure of the database is hidden from the caller, it is possible that many database changes can be made transparently. Therefore, a service in the middle tier that exchanges information/data with other applications could retain its original interface while the underlying database structure was enhanced during a new application release.
The drawbacks of the 3-tier model are as follows:
Increased Complexity/Effort: In general, it is more difficult to build a 3-tier application compared to a 2-tier application. The points of communication are doubled (client to middle tier to server, instead of simply client to server) and many handy productivity enhancements provided by client tools (e.g. Visual Basic, PowerBuilder, Delphi) will be foregone or their benefit will be reduced with a 3-tier architecture.
Fewer Tools: There are many more tools available for a 2-tier model (e.g. most reporting tools). It is likely that additional programming effort will be required to manage tasks that an automated tool might handle in a 2-tier environment.
Happy Programming
Presentation Tier
The presentation tier can include a variety of clients including standard clients (as part of a client/server application), Internet clients and reporting tools. Because business logic is implemented in the middle tier, there is relatively little duplicated effort should there be a need to provide the same function in two or more environments. For example, an Order details screen might be provided in both a client/server application and the Internet application while any business logic in the middle tier (application server) would be shared.
The presentation tier requests services from the application server but it is not limited to GUI clients. Items in the "top" tier might also include other applications that need to exchange information or data with this application.
Middle Tier (Application Server)
As mentioned earlier, the middle tier or application server might be implemented as several layers. Application servers can also be distributed on several host machines. A Transaction Processing (TP) monitor or an Object Request Broker (ORB) can be used to balance client requests across multiple database servers as well as start up/shutdown additional application server instances, as needed. Since the application server contains the business logic (where the bulk of the complex processing should occur), it is possible to support more users by adding more and faster application servers without needing to re-architect or rebuild the application.
It is not necessary to physically locate the middle tier on its own server from the beginning. In an early application release (which has a limited number of users), the middle tier might be deployed on the client machine or on the database server for simplicity. When the number of users grow (e.g. for later releases), the middle tier can then be moved onto separate server(s) so that the desired scalability benefits are obtained.
Data Tier
The data tier contains the database. It might also include data access procedures. The database can be placed in a single location or it can be distributed, if required.
The benefits of the 3-tier model are as follows:
Scalability: The key 3-tier benefit is improved scalability since the application servers can be deployed on many machines. Also, the database no longer requires a connection from every client -- it only requires connections from a smaller number of application servers. In addition, TP monitors or ORBs can be used to balance loads and dynamically manage the number of application server(s) available.
Better Re-use: The same logic can be initiated from many clients or applications. If an object standard like COM/DCOM or CORBA is employed (as discussed in tool dependence), then the specific language implementation of the middle tier can be made transparent.
Improved Data Integrity: since all updates go through the middle tier, the middle tier can ensure that only valid data is allowed to be updated in the database and the risk of a rogue client application corrupting data is removed.
Improved Security: Security is improved since it can be implemented at multiple levels (not just the database). Security can be granted on a service-by-service basis. Since the client does not have direct access to the database, it is more difficult for a client to obtain unauthorized data. Business logic is generally more secure since it is placed on a more secure central server.
Reduced Distribution: Changes to business logic only need to be updated on the application servers and do not have to be distributed to all the clients.
Improved Availability: mission-critical applications can make use of redundant application servers and redundant database servers. With redundant servers, it is possible to architect an application so that it can recover from network or server failures.
Hidden Database Structure: since the actual structure of the database is hidden from the caller, it is possible that many database changes can be made transparently. Therefore, a service in the middle tier that exchanges information/data with other applications could retain its original interface while the underlying database structure was enhanced during a new application release.
The drawbacks of the 3-tier model are as follows:
Increased Complexity/Effort: In general, it is more difficult to build a 3-tier application compared to a 2-tier application. The points of communication are doubled (client to middle tier to server, instead of simply client to server) and many handy productivity enhancements provided by client tools (e.g. Visual Basic, PowerBuilder, Delphi) will be foregone or their benefit will be reduced with a 3-tier architecture.
Fewer Tools: There are many more tools available for a 2-tier model (e.g. most reporting tools). It is likely that additional programming effort will be required to manage tasks that an automated tool might handle in a 2-tier environment.
Happy Programming
posted by .NET team @ 5:08 PM
1 Comments:
Nice writeup
Found it to be very useful as im presently thinking of using it in implementing a client's project
Post a Comment
<< Home