Why Can t the Managers Access Data Directly?

[Previous] [Next]

Why can't the main business objects handle their own data access? Why should you have to design separate classes for it?

Actually, business objects can handle their own data access, and such design patterns are probably used more frequently than our variety. And yet we can think of at least three good reasons to create separate data access classes. The one reason we find to be the most important has to do with the way Microsoft Transaction Server (MTS) and COM+ manage transactions. The second reason concerns location transparency; the third, in fact not always valid, is performance.

The COM+ and MTS Transaction Attribute Rules

As we're sure you know, COM+ and MTS both can take responsibility for transactional integrity, relieving the programmer of that responsibility. This is a useful capability, and you should definitely take advantage of it. To ensure transactional integrity, COM+ and MTS need from the developer and/or system administrator only two things:

  • Every component installed in a COM+ application or an MTS package must have a special transactional attribute set to one of four different values. This attribute helps COM+ or MTS decide whether and how to involve the component in transactions.
  • Every object involved in a transaction must tell COM+ or MTS when the component has done its job. The object must also report whether or not the job was completed successfully.

Requires, requires new, supports transactions

As Figure 12-1 shows, three of the four options of the transactional attribute—excluding the Disabled option—can involve the component's objects in transactions. The Requires New option puts the component's objects outside any ongoing transactions and so saves time and resources every time the component activates an object.

Figure 12-1. The transactional attributes in MTS.

It's a good policy to involve a component in transactions only when necessary. MTS and COM+ use a separate component, Microsoft Distributed Transaction Coordinator, or MS DTC for short, to manage transactions. Even though MS DTC is very efficient, especially when it's allowed to work with OLE Transactions, you shouldn't use it when you don't have to. You should instead design components that contain only those methods of the class that could share the same transactional attribute. Following this procedure means that you should put every method that modifies data in the database in one component and those methods that only read data from the database in another.

Figure 12-2 shows the first part of this scheme. The Save and Delete operations are put in a separate class, named HorseTrSrvcs, which is short for horse transaction services. The HorseTrSrvcs component, when installed in a COM+ application or an MTS package, should support or require transactions.

click to view at full size.

Figure 12-2. HorseTrSrvcs objects manage modifications of horse data.

Does not support transactions

Figure 12-3 completes the picture. The HorseFetcher class contains the rest of the data access methods, which are those that will never be involved in a transaction.

click to view at full size.

Figure 12-3. HorseFetcher objects handle nontransactional data access operations on Horse objects.

Revisiting the transactional attribute, assuming that all the three components in Figure 12-3 will be installed in COM+ or MTS, you get the following list of proper transactional attributes for each component.

Component Transactional Attribute
HorseManager Not Supported
HorseTrSrvcs Required
HorseFetcher Not Supported

In the preceding table, we used COM+ terms for the transactional attribute. In MTS, the attributes have slightly different names, but this difference won't cause you any problems at all. You select the transactional attribute from a number of options, and the wording is almost the same in both cases.

Location Transparency and Performance

A component in a COM+ application or an MTS package is on the same level as a class in a programming language. This sometimes makes for confusion because sometimes people say that a compiled DLL or EXE is a component and that such a component can contain several classes. When we use the word component in this book, we mean in the COM+ or MTS way; it's on the same level as a class. Having said that, we can go on to talk about location transparency.

If you put data access methods in separate components, you can put these components in separate COM+ applications or MTS packages. This arrangement, in turn, makes it possible for you to install the data access package on the server that runs the database management system. In other words, main business objects can run on an application server, whereas data access objects can run on the database server.

Of course, following this plan isn't the only deployment option open to you. Because you separate data access from main business objects on one side, and facade objects from main business objects on the other side, your deployment options are manifold. This is the idea of location transparency. You should design and develop your server components in such a way that you have many deployment strategies to choose from.

In the case of our example application, we probably won't notice any difference in performance with data access objects running on the database server as opposed to having them run on the application server. Every data access operation we've designed so far in our example application is simplistic. The network traffic will be about the same in both cases.

In other applications, or other parts of the horse racing application, the difference might be huge. If transactions are complex, as in the example described in the next paragraph, and if they involve many round-trips to the database, placing your data access objects on the database server can save a lot of network traffic. Rather than access the database several times over the network, you access the data access object only once over the network. All communication with the database is over a short distance, within the same server machine.

An example of such a complex transaction is the importing of the start lists for a race day from other systems. A start list contains 100 to 150 horses scheduled to run that day, and as many jockeys. For every horse and for every jockey included in the start list, it's necessary to check whether the horse or the jockey already exists in the database. If so, the race entry can be inserted in the database with reference to the existing horse and jockey rows. If not, the horse or the jockey, or perhaps both, must be inserted first.

Such a transaction would involve several hundred database operations. It would make a world of difference if you could send the entire start list to a data access component in the same server as the database, compared with having a remote component send each task separately over the network.

When deciding where to install your data access components, you need to consider matters other than network traffic as well. Database software, such as Microsoft SQL Server, thrives on memory. In most cases, the more memory you give such a program, the better it performs. When you run your data access components on the same computer as, for instance, SQL Server, they compete with SQL Server for memory. If it's true that reduced network traffic increases your performance, it's equally true that less memory devoted to SQL Server decreases it. For each installation, you'll have to find the balance between the increase and the decrease in performance yourself.



Designing for scalability with Microsoft Windows DNA
Designing for Scalability with Microsoft Windows DNA (DV-MPS Designing)
ISBN: 0735609683
EAN: 2147483647
Year: 2000
Pages: 133

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net