Tài liệu Module 9: The Transactional Data Access Layer pptx

Contents
Overview 1
Introduction to Transactional DAL 2
Technologies 5
Logical Design of Transactional DAL 12
Physical Design of Transactional DAL 13
Market Purchasing 18
Best Practices 21
Lab 9: Transactional DAL 22
Review 30

Module 9: The
Transactional Data
Access Layer

Information in this document is subject to change without notice. The names of companies,
products, people, characters, and/or data mentioned herein are fictitious and are in no way intended
to represent any real individual, company, product, or event, unless otherwise noted. Complying
with all applicable copyright laws is the responsibility of the user. No part of this document may
be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose, without the express written permission of Microsoft Corporation. If, however, your only
means of access is electronic, permission to print one copy is hereby granted.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual

property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.

 2000 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, ActiveX, BackOffice, BizTalk, FrontPage, Microsoft Press, MSDN,
MS-DOS, PowerPoint, Visio, Visual Basic, Visual C++, Visual InterDev, Visual J++, Visual
Studio, Win32, Windows, and Windows NT are either registered trademarks or trademarks of
Microsoft Corporation in the U.S.A. and/or other countries.

Other product and company names mentioned herein may be the trademarks of their respective
owners.

Program Managers: Rhy Mednick, Susie Parrent
Instructional Designer: Susie Parrent
Subject Matter Experts: David Chesnut, Sam Gill (TechnoWiz), Michel Pahud
Media Management: David Mahlmann
Editing Manager: Lynette Skinner
Editor: Mick Alberts, Jennifer Linn
Production Manager: Miracle Davis
Print Coordinators: Linda Lu Cannon (Write Stuff), Marlene Lambert (Online Training
Solutions, Inc.)
Build Coordinator: Eric Wagoner
Graphic Artist: Scott Serna
Test Lead: Eric Myers
Manufacturing Manager: John Williams
Group Product Manager: Juan Fernando Rivera
Lead Product Manager, System Services and Infrastructure: Edward Dudenhoefer
Manufacturing Manager: Rick Terek

Operations Coordinator: John Williams
Manufacturing Support: Laura King; Kathy Hershey
Lead Product Manager, Release Management: Bo Galford
Group Manager, Courseware Infrastructure: David Bramble
General Manager: Robert Stewart

Module 9: The Transactional Data Access Layer iii


Instructor Notes
This module provides students with a presentation on the transactional data
access layer (DAL). Module 9 is the second of two modules that focus on the
DAL: Module 8, “The Nontransactional Data Access Layer” and Module 9,
“The Transactional Data Access Layer.” The DAL is an application’s means of
access to data services.
After completing this module, students will be able to:
!
Describe the logical design of a transactional DAL and how to apply design
patterns.
!
Describe Microsoft
®
SQL Server
™
, Microsoft Distributed Transaction
Coordinator (MS DTC), and COM+ transactions and synchronization.
!
Describe the Compensating Resource Manager (CRM).
!
Describe the physical design of a transactional DAL and how to use the

technologies presented in this module.

Materials and Preparation
This section provides the materials and preparation tasks that you need to teach
this module.
Required Materials
To teach this module, you need the following materials:
!
Microsoft PowerPoint
®
file 1910A_09.ppt
!
Module 9: The Transactional Data Access Layer
!
Lab 9: The Transactional DAL

Preparation Tasks
To prepare for this module, you should:
!
Read all of the materials for this module.
!
Complete the lab.

Presentation:
60 Minutes

Lab:
60 Minutes
iv Module 9: The Transactional Data Access Layer

Module Strategy
Use the following strategy to present this module:
!
Introduction to Transactional DAL
The purpose of this section is to introduce students to the business problem
and the requirements for transactional DAL.
In the topic “Business Requirements,” emphasize the need for transactions
with either MS DTC–compliant resource managers or for compensating
transactions with CRMs.
!
TechnologiesThe purpose of this section is to introduce students to the
technologies that can be used in the physical design of the transactional
DAL.
The topics covered include the COM+ and SQL Server transaction
mechanism and the CRM architecture.
!
Logical Design of Transactional DALThe purpose of this section is to
identify the two design patterns that might be useful in the logical design of
transactional DAL: Iterator and Composite.
!
Physical Design of Transactional DALThe purpose of this section is to show
how transactions and CRM can be applied to the physical design of
transactional DAL components.
!
Market Purchasing
The purpose of this section is to discuss the logical and physical designs of
transactional DAL in Market Purchasing and to justify the choices made.
By using Component Services, you can present the Market Purchasing DAL
COM+ application. Explain that the nontransactional and transactional DAL

components are all registered in the same COM+ application because all of
the data is physically on one computer. You might also consider presenting
the source code of one of the transactional DAL components. Don’t show
the source code of the mpdaltr.Requisition or mpdaltr.LineItemDetail
classes, because that provides the answers to the lab.
!
Best Practices
The best practices focus on choosing transacted COM+ components rather
than SQL Server implicit transactions in the physical design of the
transactional DAL and the recommendation to use a CRM for
nontransactional data service providers.

Lab Strategy
!
Lab 9: The Transactional DAL
The purpose of Lab 9 is for students to learn to design the transactional
DAL. Students probably will not derive answers that correspond exactly to
the Market Purchasing design. This is acceptable as long as the student
answers are justified and reflect the principles discussed in the module.
Discuss with students their answers to Lab 9.

Module 9: The Transactional Data Access Layer 1


#
##
#

Overview
!

Introduction to Transactional DAL
!
Technologies
!
Logical Design of Transactional DAL
!
Physical Design of Transactional DAL
!
Market Purchasing
!
Best Practices


Module 9 is the second of two modules that focus on the data access layer
(DAL). In Module 8, “The Nontransactional Data Access Layer,” you learned
about data retrieval. In this module, you will learn about data manipulation.
After completing this module, you will be able to:
!
Describe the logical design of a transactional DAL and how to use design
patterns.
!
Describe Microsoft
®
SQL Server
™
, the Microsoft Distributed Transaction
Coordinator (MS DTC), and COM+ transactions and synchronization.
!
Describe the Compensating Resource Manager (CRM).
!

Describe the physical design of a transactional DAL and how to use the
technologies presented in this module.

Topic Objective
To provide an overview of
the module topics and
objectives.
Lead-in
In this module, you will learn
about the transactional DAL
and how to create logical
and physical designs for it.
2 Module 9: The Transactional Data Access Layer


#
##
#

Introduction to Transactional DAL
!
The Business Problem
!
Business Requirements


Transactional data access allows facade layer objects and business logic objects
to manipulate data from the underlying data storage systems. All of the topics
that were covered in the previous module, Module 8, “The Nontransactional
Data Access Layer (DAL),” are relevant in this module as well.

In this section, the transactional DAL will be placed in the proper context of the
business problem. This will be followed by a presentation about the business
requirements of a transactional DAL.
Topic Objective
To provide an overview of
the section topics and
objectives.
Lead-in
In this section, you will learn
what makes up a
transactional DAL.
Module 9: The Transactional Data Access Layer 3


The Business Problem
DAL
Connected Business
Logic Layer
Disconnected Business
Logic Layer
Facade Layer
Web Services Facade Business Facade
Transactional DAL
Nontransactional DAL
User Services
Data
Services


The transactional DAL facilitates both the retrieval and the modification of data

in various formats: database, Active Directory™, and file systems. Business
logic layer objects can access the transactional DAL. In general, the facade
layers do not access the transactional DAL because business logic is usually
involved during transactions.
The transactional DAL receives modification requests from the business logic
layer. The transactional DAL then processes the requests by delegating the
requests to the data services layer. The transactional DAL can return to the
business logic layer either success or failure. If the transaction also involved
retrieving data as a result of updates to the data, a recordset can be returned to
the business logic layer.
Topic Objective
To provide background
about the business problem.
Lead-in
In this topic, you will learn
about the business problem
facing designers who need
to implement a DAL.
4 Module 9: The Transactional Data Access Layer


Business Requirements
!
Transactions
!
CRMs


Transactions
Maintaining the integrity of an application’s data across multiple users and

computers is an important and difficult task. The data access associated with
transferring a student from one course to another is straightforward: you drop
the student from one course and you add the student to the other. When you
scale this operation to an enterprise application, you need an infrastructure to
carry out the transfer. What happens if the drop succeeds and the add fails?
What happens if there is a computer failure immediately after the drop is
executed but before the add is executed? For these reasons, you need an
infrastructure that provides transaction support.
CRMs
Typically, most data services are databases that can participate in a transaction,
such as SQL Server. Unfortunately, not all data services are databases. For
example, Active Directory and Extensible Markup Language (XML) files
cannot participate in transactions unless a special effort is undertaken.
Nevertheless, the business requirement is for these resources to participate in a
transaction. The solution is to implement CRM components for these resources
whose data service providers do not allow them to participate in a transaction,
thus fulfilling the business requirement.
Topic Objective
To provide background
about the business
requirements for
implementing the
transactional DAL.
Lead-in
In this topic, you will learn
about the business
requirements for
implementing transactional
DAL.
Module 9: The Transactional Data Access Layer 5

#
##
# Technologies
!
Transactions
!
Distributed Transactions
!
COM+ Transactions
!
Architecture of CRM


The design of components for the transactional DAL is based on the same data
access technologies as that of the nontransactional DAL. The following data
access technologies were covered in Module 8, “The Nontransactional Data
Access Layer”:
!
Microsoft Data Access Components (MDAC)
!
OLE DB
!
ActiveX
®
Data Objects (ADO)
!
Record
!

Stream
!
Cursor Service
!
Data Shaping Service
!
XML
!
Active Directory Service Interfaces (ADSI)

The design of physical components for the transactional DAL is based on using
transactions. In this section, you will learn about the following transaction
technology topics:
!
Transactions
!
Distributed transactions
!
COM+ transactions

In addition, in this section you will learn about the architecture of the CRM.
Topic Objective
To provide an overview of
the section topics and
objectives.
Lead-in
In this section, you will
review the technologies
associated with
transactional DAL.

6 Module 9: The Transactional Data Access Layer


Transactions
!
Local Transactions in SQL Server
$
Explicit
$
Implicit
!
Avoid Local Transactions When Using COM+ and the
MS DTC
!
Active Directory Transactions


In the transactional DAL, you need to create simple transactions that can affect
one row in one table at a time and complex transactions that can affect multiple
rows in multiple tables.
Local Transactions in SQL Server
By default, SQL Server is in autocommit mode. In this mode, each SQL
statement, such as UPDATE or INSERT, is encapsulated in a separate
transaction as it is run. You can change this behavior by using explicit or
implicit transactions. To use an explicit transaction, you issue a BEGIN
TRANSACTION statement followed by the SQL statements that are to be run
inside the transaction. Then you issue a COMMIT TRANSACTION or
ROLLBACK statement to either commit or roll back the transaction.
To use implicit transactions, you issue the statement SET
IMPLICIT_TRANSACTIONS ON. The next SQL statement you issue, such as

UPDATE or INSERT, will begin a new transaction. The transaction will end
when you issue a COMMIT TRANSACTION or ROLLBACK statement. Then
the next SQL statement will implicitly begin yet another transaction.
Avoid Local Transactions When Using COM+ and the MS
DTC
When using the MS DTC or COM+ transactions, you should avoid using
implicit or explicit transactions since the SQL statements you issue will run
inside the distributed transaction. Beginning new transactions, implicitly or
explicitly, can be semantically confusing and might cause problems with the
distributed transaction.
Topic Objective
To provide a review of
transactions.
Lead-in
In this topic, you will learn
how to design transactions
in the transactional DAL.
Module 9: The Transactional Data Access Layer 7


Active Directory Transactions
Active Directory does not participate in transactions with the MS DTC.
Therefore, any changes you make to Active Directory from withina transaction
cannot be rolled back if the transaction aborts.
However, you can create CRMs to make some of the ADSI interfaces
transactional. For example, when accessing properties in Active Directory it is
possible to cache the properties locally, and to manipulate the properties in the
local cache.
A CRM can use the cache to write properties while the transaction is pending.
When the transaction commits, the CRM writes the properties to the underlying

directory store. If the transaction aborts, the properties are not saved.
8 Module 9: The Transactional Data Access Layer


Distributed Transactions
MS DTC
MS DTC
UPDATE UPDATE


For complex transactions that involve data modifications on multiple rows in
multiple tables on databases that are on multiple computers, there is a protocol
for implementation named two-phase commit (2PC). The name 2PC is derived
from fact that this protocol divides a transaction into two phases: a prepare
phase (variable time) and a commit phase (fixed time).
The MS DTC uses 2PC to manage and implement complex transactions. MS
DTC can be used with various types of transaction participants that adhere to
the XA standard for transactions. In 1991, The X/Open standards group
introduced a standard, named the Distributed Transaction Processing (DTP)
model, and two standard interfaces. The first interface is TX, a standard
application programming interface (API) that applications can use to interact
with a transaction manager. The second interface is XA, a standard API that
transaction managers such as MS DTC can use to interact with resource
mangers such as SQL Server.
You can create explicit distributed transactions with a SQL Server BEGIN
DISTRIBUTED TRANSACTION statement. However, this technique is
counterproductive if the application is using COM+ components to define a
complex transaction, as it should. COM+ uses MS DTC to manage complex
transactions.
Topic Objective

To provide a review of
distributed transactions.
Lead-in
In this topic, you will learn
the details of the physical
design of distributed
transactions.
Module 9: The Transactional Data Access Layer 9


COM+ Transactions
COM+
Transfer
Add
Drop


Implement each individual transaction that is in a complex transaction as a
separate COM+ component, and configure the component as Participating in a
Transaction in Component Services. The complex transaction should also be a
COM+ component configured as Participating in a Transaction in Component
Services, and should create instances of the participating simple transactions by
using the context object. For further information about how to create and
manage transactions, refer to Module 4, “Managing Transactions and State,” in
Course 1907A: Building Distributed Applications for Microsoft Windows 2000
with Visual Basic.
In the preceding slide, there is an illustration of COM+ invoking a complex
transactional DAL component, Transfer, which is composed of two
transactional DAL components, Drop and Add.
Topic Objective

To provide an overview of
COM+ transactions.
Lead-in
In this topic, you will learn
how to create a physical
design with COM+
transactions.
10 Module 9: The Transactional Data Access Layer


Architecture of CRM
CRM
Compensator
Log
File
1
2
3
CRM
Clerk
CRM
Worker
Application Component


Prior to COM+, it was not possible for nontransactional resources to participate
in MS DTC transactions. However, the addition of CRMs in COM+ has made
this functionality possible. This topic introduces the components of the CRM
architecture and their interactions.
CRMs provide an alternative to developing full resource managers. For

example, if you want to make updates to an XML file in the context of a
transaction, you have to build a resource manager for XML files. The resource
manager would be responsible for voting on the outcome of the transaction and
for committing or rolling back changes to the XML file, depending on the final
result of the transaction. Building this type of resource manager is not easy, but
the CRM provides an architecture that makes it easier to include resources such
as XML files in transactions.
To build a CRM, you must create two components: a CRM Worker and a CRM
Compensator. The CRM Worker is responsible for performing the work on the
resource. In the case of an XML file, it updates the XML. The CRM Worker
also exposes a custom interface for the client component to use. For example,
for XML files it might expose a method named WriteToXML. The CRM
Compensator is responsible for participating in the two-phase commit. It
responds to each phase, ultimately committing the changes or rolling them back
depending on the outcome of the transaction.
Operation of CRM
The first step in the operation of the CRM is the client component’s creation of
the CRM Worker. The client component then begins using the CRM Worker. In
the case of the XML CRM Worker, the client component would call the
WriteToXML method to write some XML to a file.
Topic Objective
To define how CRM is used
in the physical design.
Lead-in
In this topic, you will learn
how and when to include
CRM in your physical
design.
Module 9: The Transactional Data Access Layer 11

The second step is the CRM Worker’s use of another component provided by
COM+: the CRM Clerk. The CRM Worker uses this component to write log
records to a durable log. The log records are important because they provide a
written record of the work done. If a system failure occurs, a recovery can be
initiated, and the log records can be used to roll back the changes that were
made.
When the client is finished and calls SetComplete or SetAbort, the third step
begins. The CRM Clerk calls the CRM Compensator so that CRM
Compensator participates in the outcome of the transaction. The CRM
Compensator receives notifications from the CRM Clerk about the outcome of
the transaction. The CRM Compensator is also used to perform recovery when
a failure occurs.
The CRM Compensator is responsible for providing the compensating action.
The CRM Compensator implements a defined interface by which it is notified
of prepare, commit, and abort. During the prepare phase, the CRM
Compensator can vote on whether or not to commit the transaction. If it detects
a problem (such as running out of disk space) it aborts the transaction. During a
commit, the CRM Clerk will send the log records to the CRM Compensator so
that the CRM Compensator can commit the work. During an abort, the CRM
Clerk will still send the log records so that the CRM Compensator can roll back
or compensate the work that was performed by the CRM Worker.
A durable log is provided so that your application resources can write records
that survive failures. The CRM feature automatically provides recovery on this
log file when the application restarts.
12 Module 9: The Transactional Data Access Layer


Logical Design of Transactional DAL
!

Iterator
!
Composite


The transactional DAL logical design can use the same design patterns as that
of the nontransactional DAL: the Iterator and Composite patterns.
Iterator
The Iterator design pattern allows a client to access a collection of objects
without relying on the internal structure of those objects. In the DAL, you will
frequently be dealing with collections of records being passed back and forth
across the system. The Iterator is an excellent design pattern to model record
collections, and frequently the Iterator is implemented as a recordset.
Composite
The Composite design pattern combines multiple types of objects into tree
hierarchies or part/whole hierarchies. Data often has hierarchical or part/whole
relationships. For example, in a bill of materials a part might also be an
assembly of other parts. Although the Composite design pattern is a structural
design pattern, it works very well to help organize data. Often the Data Shaping
Service implements the Composite design pattern.
Topic Objective
To provide information
about the logical design of a
transactional DAL.
Lead-in
In this topic, you will learn
about the design patterns
that can be applied to a
transactional DAL.
Module 9: The Transactional Data Access Layer 13

#
##
# Physical Design of Transactional DAL
!
Transactional Physical Design
!
CRM Physical Design
!
Components


In this section, you will learn about the physical design of the transactional
DAL. In particular, you will learn about designing transactions and a CRM.
You will then learn how to design the COM+ components that implement the
transactional DAL.
Topic Objective
To provide an overview of
the section topics and
objectives.
Lead-in
In this section, you will learn
about the physical design
considerations of a
transactional DAL.
14 Module 9: The Transactional Data Access Layer


Transactional Physical Design

!
COM+
!
MS DTC


In general, all updates to databases should be transacted. Embed simple
transactions in a COM+ component. Design complex transactions as a
hierarchy of COM+ components that invoke simple transaction components.
COM+, through MS DTC, will manage the hierarchy of complex data
modification components and their participation in transactions.
Avoid the explicit use of distributed transactions through MS DTC when
creating an enterprise system that uses COM+ components. The COM+
components already support transactions, eliminating the need for you to write
MS DTC code. Also, MS DTC code that you write could interfere with COM+
transactions in the system.
Topic Objective
To provide a summary of
transactions.
Lead-in
In this topic, you will learn
about the important physical
design issues associated
with transactions.
Module 9: The Transactional Data Access Layer 15


CRM Physical Design
!
CRM Worker

!
CRM Compensator


To implement CRM, you need to create the physical design for two COM+
components:
CRM Worker
The CRM Worker implements a COM interface specific to the task it is
designed to perform. The application component must be running under a
transaction so that the CRM Worker inherits the transaction of the application
component. CRM Workers always require a transaction. The CRM Worker
causes the CRM Compensator to be instantiated.
The CRM Worker writes records to the durable log obtained from the CRM
Clerk. The CRM Worker registers the name of the CRM Compensator to use
with the CRM Clerk.
The CRM Worker must perform “write ahead.” That is, it must write a record to
the log describing the action before it actually performs the action.
When the CRM Worker is done with its actions, it is finished writing and
forcing records to the log.
CRM Compensator
The CRM Compensator is also a COM+ component. The CRM Compensator is
first notified of the prepare phase of the transaction completion, and can vote
either yes or no to the prepare request. If the CRM Compensator votes no, then
it will not receive any further abort notifications. If it votes yes to the prepare
request, then the CRM Compensator will receive either the commit or abort
notifications. A CRM Compensator uses the abort notification to reverse the
action that was performed by the CRM Worker. The CRM Compensator does
not run under a MS DTC transaction.
For more information about CRM and physical design, see the keyword “design
suggestions” under the “Compensating Resource Managers” section in the

Platform SDK Help in Microsoft MSDN
®
Library.
Topic Objective
To provide a summary of
CRM.
Lead-in
In this topic, you will learn
about the important design
considerations for CRM
components.
16 Module 9: The Transactional Data Access Layer


Components
!
Transactional Support
!
Synchronization
!
Activation


It is recommended that you implement the transactional DAL using COM+
components. COM+ provides synchronization, activation, transaction, and
security services. Therefore, the best approach is to let COM+ handle these
services while you program the logic of your components.
Transactional Support
The transactional DAL requires transactions. Therefore, configure the classes as
Required or Requires New. This ensures that the classes will always run inside

a transaction.
If you have COM+ classes that make singular updates to a single database, you
can configure their transaction attributes as Supported. In the context of a single
update on a single database, it is not necessary to use MS DTC. The database
will provide a local transaction automatically for a single update. This reduces
overhead on the simple update by not bringing in the MS DTC.
In a more complex case, in which multiple COM+ classes are using multiple
databases, the Supported class will still work correctly. When it is called by one
of the complex classes in which a distributed transaction is running, the simple
class will join the transaction and participate in its outcome.
Synchronization
For classes in the transactional DAL, use the neutral threading model, which is
a more scalable threading model. For Microsoft Visual Basic
®
components, use
the apartment threading model, since the neutral threading model is not
supported.
You must configure the classes to require synchronization. The use of
transactions in COM+ requires that the classes inside those transactions be
synchronized.
Topic Objective
To present issues and
configuration information
related to COM+
transactional support,
synchronization, and
activation services.
Lead-in
In this topic, you will learn
about ssues and

configuration information
related to COM+
transactional support,
synchronization, and
activation services.
Module 9: The Transactional Data Access Layer 17


Activation
Because the transactional classes require transactions and synchronization, they
must support just-in-time (JIT) activation. The best way to support activation
from a transactional class is to vote on the transaction outcome. If a method call
successfully completes its work, you can call IObjectContext::SetComplete.
If a method call fails for some reason, call IObjectContext::SetAbort to abort
the transaction.
Calling SetComplete or SetAbort will cause your object instance to be
deactivated when the current method call returns to the caller. If your object
requires that more work be completed before deactivation, you can call
IObjectContext::EnableCommit or IObjectContext::DisableCommit before
exiting the method call. For more information about EnableCommit and
DisableCommit, see MSDN Library.
JIT activation requires that your components conform to a stateless
programming model. Therefore, you should write the methods for the interfaces
to either store, update, or retrieve data. The interfaces should not store
properties. For example, if you have a customers table and a Customers class,
the Customers class should have an interface with methods such as
GetCustomer, CreateCustomer, and UpdateCustomer, which pass all of the
necessary parameters for working with a customer. The interface should not
have methods such as SetName or GetName, which set individual properties of
the customer before taking an action like creating or getting customer records.

In addition to the preceding attributes, the topics covered in the previous
module, Module 8, “The Nontransactional Data Access Layer,” apply. In
particular, the information about object pooling, the constructor string, security,
and packaging and deployment also applies to the transactional DAL.
18 Module 9: The Transactional Data Access Layer


#
##
# Market Purchasing
!
Market Purchasing Logical Design
!
Market Purchasing Physical Design


In this section, you will learn how the logical and physical design guidelines
were applied to the transactional DAL of Market Purchasing.
Topic Objective
To provide an overview of
the section topics and
objectives.
Lead-in
In this section, you will learn
how the logical and physical
designs were applied to the
Market Purchasing
transactional DAL.
Module 9: The Transactional Data Access Layer 19

Market Purchasing Logical Design
!
Uses the Iterator Design Pattern for Data Sets
!
There Is One Design Class for Each Entity
!
Both a Worker Class and Compensator Class
Are Created for an XML CRM


The logical design for the transactional DAL for Market Purchasing, as shown
in the preceding slide, incorporates several principles:
!
The Iterator design pattern is used to represent data sets.
!
There is one design class for each entity in the database.
Thus the LineItemDetail entity has a daltr_LineItemDetail class, the
Requisition entity has a daltr_Requisition class, and so forth.
!
Because Market Purchasing must write to XML files in the context of a
transaction, a CRM for XML files was designed. Both a Worker class and a
Compensator class were designed for writing to XML files.

The naming convention is to use a prefix of daltr (data access layer
transactional) for each class.
Topic Objective
To provide an overview of
the logical design for the
Market Purchasing

transactional DAL.
Lead-in
In this topic, you will learn
how the logical design for
the Market Purchasing
transactional DAL was
implemented.
20 Module 9: The Transactional Data Access Layer


Market Purchasing Physical Design
Market Purchasing DAL
COM+ Application
mpdaltr.Requestor
mpdaltr.Country
mpdaltr.Part
mpdaltr.Requisition
Market Purchasing XML CRM
COM+ Application
mpXMLCRM.Compensator
mpXMLCRM.Worker


The physical design for the transactional DAL for Market Purchasing, as shown
in the preceding slide, incorporates several principles:
!
One COM+ class is created for each table in the database.
For example, mpdaltr.Requisition contains all methods for updating data
in the Requisition table.
!

The COM+ classes are contained in one dynamic-link library (DLL) called
mpdaltr.dll.
!
The mpdaltr.dll is registered in the Market Purchasing DAL COM+
application.
!
The CRM classes are contained in a DLL called mpXMLCRM.dll.
!
The mpXMLCRM.dll is registered in the Market Purchasing XML CRM
COM+ application, which is configured to support CRMs.

The naming convention is to use the name mpdaltr (Market Purchasing data
access layer transactional) for the DLL file name.
Topic Objective
To provide an overview of
the physical design for the
Market Purchasing
transactional DAL.
Lead-in
In this topic, you will learn
the how physical design for
the Market Purchasing
transactional DAL was
implemented.
Module 9: The Transactional Data Access Layer 21


Best Practices
!
Transacted components are preferred over transacted

SQL.
!
Use a CRM for nontransactional data service providers.


There are two important best practices that emerge with respect to the logical
and physical designs of the transactional DAL:
!
Always implement transactions by using COM+ rather than SQL Server for
better performance and better management of complexity.
!
When you are working with data services that do not support transactions
(that is, data services that are not MS DTC resource managers) implement a
CRM for these resources to allow them to participate in transactions.

Topic Objective
To provide a discussion of
the best practices for the
logical and physical designs
of the transactional DAL.
Lead-in
In this topic, you will learn
two best practices for the
design of the transactional
DAL.