Microsoft has been committed to n-tier development for a very long time. It was the heart of the now-deprecated Distributed interNet Architecture (DNA) introduced in 1999, and it remains the heart of .NET today. As noted earlier, n-tier really means “three or more” tiers. The “required” three are the presentation (user interface), business logic, and persistence (data) layers.
It is possible, of course, to have many more than three tiers. For example, some developers find it useful to break up the application layer into a workflow and a rules layer, and to break up the persistence layer into a data layer that exists in the application and a data layer that is implemented in stored procedures and thus exists on the database server.
The key to solid n-tier development is clean separation between the layers. The presentation-layer objects should know as little as possible about the internals of the business objects, and they certainly should know nothing about how the data they represent is persisted.
The arguments for this decoupling between the layers only grow stronger as we face a rapidly changing and evolving development environment. The presentation options are proliferating more quickly than we can learn how to code for them, and the kinds of data (and the volume of data) that we must present are expanding exponentially.
We are no longer in the position of just extracting data from a database and presenting it as a simple web form. Now, we are just as likely to be aggregating data from mail messages, spreadsheets, XML documents, queries from various databases, and values retrieved from web services, and presenting them both over the Web and on mobile devices. Furthermore, all of this is mediated by business rules that determine which users have access, editing, and manipulation rights and takes place in an environment in which the tools and the specifications are in a near-constant state of flux.
Source of Information : OReilly Programming dot NET 3.5
It is possible, of course, to have many more than three tiers. For example, some developers find it useful to break up the application layer into a workflow and a rules layer, and to break up the persistence layer into a data layer that exists in the application and a data layer that is implemented in stored procedures and thus exists on the database server.
The key to solid n-tier development is clean separation between the layers. The presentation-layer objects should know as little as possible about the internals of the business objects, and they certainly should know nothing about how the data they represent is persisted.
The arguments for this decoupling between the layers only grow stronger as we face a rapidly changing and evolving development environment. The presentation options are proliferating more quickly than we can learn how to code for them, and the kinds of data (and the volume of data) that we must present are expanding exponentially.We are no longer in the position of just extracting data from a database and presenting it as a simple web form. Now, we are just as likely to be aggregating data from mail messages, spreadsheets, XML documents, queries from various databases, and values retrieved from web services, and presenting them both over the Web and on mobile devices. Furthermore, all of this is mediated by business rules that determine which users have access, editing, and manipulation rights and takes place in an environment in which the tools and the specifications are in a near-constant state of flux.
Source of Information : OReilly Programming dot NET 3.5
|
|
0 comments
Post a Comment