Maximizing.ASP.dot.NET.Real.World.ObjectOriented.Development [Electronic resources] نسخه متنی

The Benefit of Splitting Applications into Layers

In large corporations that have large software applications, teams of developers and analysts concentrate on specific layers of the application. This is necessary because it would be difficult for developers to understand at a detailed level everything that's going on. The application is just too big.

Imagine all of the functions that an insurance company's application must perform. To really oversimplify the process, let's say that the company must be able to accept a new insurance policy, rate the risk involved with that policy, bill the insured, print out the policy and mail it, process claims against the policy, renew the policy, cancel the policy if it expires (or hasn't been paid for!), and so on. This huge process isn't handled by a single desktop application, obviously!

Web applications are easily split into layers as well, in some cases whether you want to or not. If you store data in a SQL Server database, the database is already its own layer, separate from the Web server (even if they're both physically on the same box).

One of the biggest complaints about the old Active Server Pages was that you had a mess of code intertwined in your HTML, and it was hard to maintain. Developers back then would frequently break out data access, and even the generation of HTML in some cases, into COM components that made the separation of code and presentation (i.e., the HTML) more clear.

ASP.NET, being an object-oriented platform, makes it even easier to break out these layers. Application layers make life easier because they encapsulate some higher purpose into a discrete unit that can be maintained or altered by itself, distributing the work of your application as well as the workload of maintaining it.

Your favorite online retailer probably has a number of application layers. Let's assume that a retailer has layers that work together in the manner described in Figure 4.1.

The diagram shows a combination of physical hardware layers and application layers. The Web server actually has three layers running on it. The first part generates the user interface for the Web user. It's fed by the business rules layer, which decides what data to send to the UI. The business rules layer talks with the data access layer, which works through a transaction router to get the data it needs. Other systems for the customer service representatives and the warehouse also get data as needed from the transaction router.

Each layer only cares about its function. The business rules layer doesn't need to know anything about the data store itself; it only needs to know about the interface offered by the data access layer. In fact, it doesn't care what kind of database is out there, or even if there's a database at all. It only cares that there's a data access layer that it can talk to, and that it will give and take data as needed via an agreed upon interface.

Although there should be some kind of integration testing for the entire system, we can change the innards of any one layer without having to disturb other layers, provided that the agreed upon interfaces are not changed.