Tài liệu Module 8: The Nontransactional Data Access Layer doc

Contents Overview 1 Introduction to the Data Access Layer 2 Nontransactional DAL Technologies 5 Logical Design of Nontransactional DAL 24 Physical Design of Nontransactional DAL 28..

Contents

Overview 1

Introduction to the Data Access Layer 2

Nontransactional DAL Technologies 5

Logical Design of Nontransactional DAL 24

Physical Design of Nontransactional DAL 28

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

Instructor Notes

This module provides students with a presentation on the nontransactional data access layer (DAL) Module 8 is the first 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 differences between the two types of DALs: transactional and nontransactional

! Describe the logical and physical designs of a nontransactional DAL and how to apply behavioral design patterns

! Describe the data access technologies provided by Microsoft® Data Access Connectivity (MDAC)

! Describe the cursor engine and how to create the physical design for data caching by using the cursor engine

! Implement the logical and physical designs for a nontransactional DAL object

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_08.ppt

! Module 8: The Nontransactional Data Access Layer

! Lab 8: The Nontransactional DAL

Preparation Tasks

To prepare for this module, you should:

! Read all of the materials for this module

! Complete the lab

Presentation:

75 Minutes

Lab:

30 Minutes

Demonstration

This section provides demonstration procedures that will not fit in the margin notes or are not appropriate for the student notes

ADSI

! To prepare for the demonstration

• Review the instructions in the student notes

Module Strategy

Use the following strategy to present this module:

! Introduction to the Data Access Layer The purpose of this section is to introduce students to the DAL and its main purpose, which is to buffer all other layers from the data services layer The section also emphasizes the need to split the DAL into nontransactional and transactional layers to define the proper boundaries for COM+ applications and their attributes

In the topic “Splitting the DAL,” emphasize that the key functions for the nontransactional DAL are to receive requests from the business or Web services facade layer or business logic layer, to process the requests and pass the requests to data services, to retrieve the results from data services, and to pass the results of the processing back to the facade layer or business logic layer

! Nontransactional DAL TechnologiesThe purpose of this section is to introduce students to the technologies that can be used in the physical design of the DAL This is a long list of technologies that can be used by both nontransactional and transactional DALs

In the topic “Microsoft Data Access Components (MDAC)” emphasize the history of MDAC and how the Microsoft Universal Data Access (UDA) strategy has evolved over the past decade

In the topic “ADO,” emphasize that ActiveX® Data Objects (ADO) have replaced Data Access Objects (DAO) and Remote Data Objects (RDO) as the standard for writing data-aware applications

In the topic “Cursor Service,” emphasize that this is a service provided by OLE DB and that the Cursor Service can be installed on each tier of a multitier application to provide an effective solution for scalability

In the topic “Active Directory Service Interfaces (ADSI),” emphasize that this is recommended as the primary mechanism for creating and changing objects and schemas within the Active Directory™ services

! Logical Design of Nontransactional DALThe purpose of this section is to identify the two design patterns that might be useful in the logical design of nontransactional DAL: Iterator and Composite

! Physical Design of Nontransactional DALThe purpose of this section is to show how DAL technologies can be applied to the nontransactional DAL

! Market Purchasing The purpose of this section is to discuss the logical and physical designs of nontransactional DAL in Market Purchasing and to explain the justification for the choices made The logical design incorporates an Iterator while the physical design uses cursors and ADO for database access

By using Component Services, you can present the Market Purchasing DAL COM+ application Explain that both the nontransactional and transactional DAL components are registered in the same COM+ application because all

of the data is physically on one computer You may also consider presenting the source code of one of the nontransactional DAL components Don’t

show the source code of the mpdalnt.Requestor class, since that will give

away the answers to the lab

! Best Practices The best practices focus on using an Iterator as a design pattern for a class rather than having a separate collection class for each business entity The physical design best practices focus on the efficient use of cursors: client vs server side

Lab Strategy

! Lab 8: The Nontransactional DAL The purpose of Lab 8 is for students to learn how to design the nontransactional 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 8

# Overview

! Introduction to the Data Access Layer

! Nontransactional DAL Technologies

! Logical Design of Nontransactional DAL

! Physical Design of Nontransactional DAL

After completing this module, you will be able to:

! Describe the differences between the two types of DALs: transactional and nontransactional

! Describe the logical and physical designs of a nontransactional DAL and how to use behavioral design patterns

! Describe the data access technologies provided by Microsoft® Data Access Connectivity (MDAC)

! Describe the cursor engine and how to create the physical design for data caching using the cursor engine

! Implement the logical and physical designs for a nontransactional DAL object

In this module, you will learn

about the nontransactional

data access layer and how

to create a logical design

and a physical design for it

# Introduction to the Data Access Layer

! The Business Problem

! Splitting the DAL

The DAL buffers the entire system from the underlying data services All access to data services for creating, updating, or deleting is accomplished through the DAL

In this section, the DAL is introduced and discussed in the context of the business problem for accessing data services You will also learn about the technologies necessary to implement the nontransactional DAL Many of these technologies are also used for the transactional DAL, which is discussed in Module 9, “The Transactional Data Access Layer.”

In this section, you will learn

about what makes up a

nontransactional DAL

The Business Problem

Data Access Layer

Connected Business Logic Layer

Disconnected Business Logic Layer

Facade Layer

User Services

Data Services

The data services store and manage all of the data used by the system Access to the data services requires detailed knowledge of where and how the data is stored For example, an order entry system might store orders in several tables

in a Microsoft® SQL Server™ database To create a new order, a system must know the name of the computer running SQL Server, the name of the database, and the names of the tables in which the orders are stored

If the business logic or facades were to access the data services directly, they would have to be programmed and compiled with much of this information in the components Changes to the data services, such as changing the computer name, database name, or table structures, would require changes in the business logic and facades

A DAL isolates the rest of the system from changes in the data services Using the DAL, the business logic or facades only pass or request the data they need, without any dependency on where or how that data is stored The DAL is programmed with the information necessary to locate data servers and update the data Therefore changes to the data services will require only the DAL to be recompiled, not any components in the business logic or facades

A subtle but important detail in this architecture is that the business and Web services facades can access the DAL directly If the facades need to retrieve or update data in a manner that does not require business logic to be involved, there is no need to go through the business logic layer The facades simply access whatever components they need in the DAL to accomplish their goals

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

Splitting the DAL

! Nontransactional only applies to retrieving data.

! Transactional only applies to creating, updating, and deleting data.

! COM+ declares transactions at a class level.

! Split entity classes into transactional and nontransactional classes.

The DAL is split into two separate parts One part, called the nontransactional DAL, only exposes functionality to retrieve data The other part, called the transactional DAL, exposes functionality to create, update, and delete data The DAL is split into two parts because transactions take a lot of overhead When a COM+ class declares that it requires transactions, the Microsoft Distributed Transaction Coordinator (MS DTC) must create and manage the transactions This overhead is not necessary when only retrieving data, so the methods dealing with data retrieval are put in the nontransactional DAL

This is an important distinction because most classes you derive in your logical design will combine transactional and nontransactional methods For example,

a customers table in the database should have a Customers class that exposes methods such as GetCustomer, CreateCustomer, and UpdateCustomer GetCustomer is a nontransactional method because it does not change the table However, CreateCustomer and UpdateCustomer require a transaction

to update the database

COM+ declares transactions at a class level Either the entire class requires transactions, or the entire class does not support transactions Therefore the

GetCustomer method is split off into another class, which only has methods

that retrieve data

In your logical design, you should already have this architecture in mind while creating classes for the DAL

The following are the key functions for the nontransactional DAL:

! Receive requests from the business or Web services facade layer or business logic

! Process the requests and pass them to data services

! Retrieve the results from data services

! Pass the results of the processing back to the facade layer or business logic

Topic Objective

To discuss the advantage of

splitting off certain pieces of

the DAL into transactional

and nontransactional

components

Lead-in

In this topic, you will learn

about the reasons for

splitting the DAL into two

separate parts

# Nontransactional DAL Technologies

! Microsoft Data Access Components

! Data Shaping Service

! Issues and Challenges of Data Exchange

! XML Solution

! Active Directory Service Interfaces

The design of components for the nontransactional DAL is based on data access technologies for accessing hierarchical as well as non-hierarchical data In this section, the following data access technology topics will be covered in detail:

! Microsoft Data Access Components (MDAC)

! Data Shaping Service

! Extensible Markup Language (XML) solution

! Active Directory™ Service Interfaces (ADSI)

In this topic, you will learn

about the technologies for

implementing

nontransactional DAL

Microsoft Data Access Components

Other Data Sources

Other Data Sources Databases Relational Databases Relational

Data Object Interfaces

Data Object Interfaces

Application Programming Interfaces

Application Programming Interfaces

ODBC OLE DB

Microsoft Data Access Components (MDAC) version 2.5, which is integrated into Microsoft Windows® 2000, provides the key technologies that enable Universal Data Access (UDA) UDA is a definition of Microsoft's strategy for providing access to information across the enterprise

MDAC includes ADO, OLE DB, and Open Database Connectivity (ODBC) The MDAC technology can be used in the physical design of nontransactional DAL components to easily integrate information from a variety of sources, both relational (SQL) and non-relational

History of MDAC

The Microsoft Universal Data Access (UDA) strategy has evolved during the past decade It began with Data Access Objects (DAO), an object wrapper that interacted with the Jet engine (a query service), and connected to data sources through ODBC DAO was designed to interact with Microsoft Access databases DAO, however, had serious shortcomings, particularly in performance when it was used with large databases such as SQL Server This is because it used the Jet engine as its query engine To overcome the shortcoming

of DAO, Microsoft introduced Remote Data Objects (RDO) RDO interacted directly with ODBC drivers RDO was an improvement over DAO, but it was limited to relational database sources

To facilitate performance and the ability to interact with different types of data sources, Microsoft introduced OLE DB OLE DB allows development of provider applications and consumer applications that facilitate data transfer and manipulation with different data sources

To avoid needing to immediately create a large number of OLE DB providers for different data sources, Microsoft introduced an OLE DB generic provider that can communicate with ODBC drivers

In this topic, you will learn

about the MDAC

technology

This brings us to MDAC MDAC is a packaging of OLE DB, ADO, and ODBC MDAC provides universal access to many different data sources by using a universal mechanism Microsoft has introduced extensions to both OLE

DB and ADO for specific data sources, such as ActiveX Data Objects Multidimensional (ADO MD), which provides access to multidimensional data generated by Microsoft Analysis Services

For more information on MDAC, see the Microsoft Universal Data Access Web site at http://www.microsoft.com/data

SQL Server

ADO Consumer

SQL Server OLE DB Provider

Data Shaping Service

Microsoft OLE DB defines a set of interfaces that can expose data from a variety of relational and nonrelational sources by using the Component Object Model (COM) OLE DB components consist of data providers, which contain and expose data; data consumers, which use data; and service components, which process and transport data (such as query processors and Cursor Engines) In addition, OLE DB includes a bridge to ODBC to enable continued support for the broad range of ODBC relational database drivers

OLE DB makes it easy for applications to access data stored in relational and nonrelational data sources OLE DB applications can be classified broadly into two categories: consumers and providers

Consumers

A consumer is any application code that consumes an OLE DB interface An example of a consumer is a Visual Basic® application that accesses an Access database In our Enterprise Architecture, the consumer would be the DAL

Topic Objective

To provide a review of OLE

DB

Lead-in

In this topic, you will learn

about the architecture of

OLE DB

! Service providers

A service provider, in general, does not have its own data, but facilitates data access between a data provider and a consumer Examples of service providers are query processors and Cursor Engines Service providers act both as consumers and providers As a consumer, a service provider retrieves data from the underlying data provider As a provider, it creates a rowset from the retrieved data and returns it to the consumer

OLE DB functionality is exposed through more than 50 different interfaces Relatively few of these interfaces are mandatory Since most interfaces are optional, this allows a provider to implement only the functionality it needs Thus, OLE DB allows providers to better match and expose information functionality

Defining new interfaces can extend the OLE DB functionality This allows providers to expose custom functionality that cannot be exposed through ODBC For example, Microsoft Analysis Services for SQL Server has an OLE DB MD provider

ActiveX Data Objects

! ADO Object Model

! ADO Programming

! Remote Data Service

ADO provides an object model and an associated programming model that defines the sequence of activities necessary to gain access to and update a data source The programming model summarizes the entire functionality of ADO The objects in ADO expose methods, which perform some operation on data and properties, which either represent some attribute of the data or control the behavior of some object method

ADO Object Model

ADO uses OLE DB to access and work with data The object model is an abstraction of OLE DB, which makes it easier to work through OLE DB The

object model consists of three primary objects: Connection, Recordset, and Command

The Connection object represents a live connection to the data source The Connection object is used to execute commands and retrieve data from the data

The Command object is used to execute commands against the data source It

can be used to specify parameters and the type of command, such as SQL text,

stored procedure name, or just a table name, to retrieve The Command object can be used in conjunction with a Connection object, or it can be used

separately, in which case it creates an internal Connection object to access the

In this topic, you will learn

about the architecture of

ADO

ADO Programming

ADO provides the means for an application to perform the following sequence

of actions:

1 Connect to a data source

2 Specify a command to gain access to the data source

3 Execute the command

4 If the command causes data to be returned in the form of rows in a table, store the rows in a cache that you can easily examine, manipulate, or change

5 If appropriate, update the data source with changes from the cache of rows

6 Provide a general means to detect errors (usually as a result of making a connection or executing a command)

Remote Data Service

In addition, ADO provides an interface, Remote Data Services (RDS), which allows you to gain access to a data source through an intermediary, such as Internet Information Services (IIS)

RDS provides the means for a remote application to perform the following sequence of actions:

1 Specify the program to be invoked on the server, and obtain a way to refer

to it from the client

2 Invoke the server program Pass parameters to the server program that identify the data source and the command to issue

3 The server program obtains a Recordset object from the data source

4 The server program returns the final Recordset object to the client

application

5 On the client, the Recordset object is processed

6 Any modifications to the Recordset object on the client are sent back to the

server program, which uses them to update the data source

Record

! Represents an Individual Row of a Recordset, or a Resource (Such As a File or Directory) in a File System

! Used to Access Hierarchical Data in a Web Site

The Record object in ADO represents a row in a recordset, or a file or directory

in a file system The Record object is ideal for working with hierarchical data The Record object can model tree-structured namespaces Each node in the tree

is represented by a Record object with associated columns The columns represent the attributes of that node and other relevant information The Record

object can represent both a leaf node and a nonleaf node in the tree structure Nonleaf nodes have other nodes as their contents while leaf nodes do not have such contents Leaf nodes typically contain binary streams of data while nonleaf nodes might also have a default binary stream associated with them Properties

on the Record object identify the type of node

The Record object also represents an alternative way for navigating hierarchically organized data A Record object may be created to represent the root of a specific sub-tree in a large tree structure, and new Record objects may

be opened to represent child nodes

A file or directory (that is, a resource) is uniquely identified by an absolute

Uniform Resource Locator (URL) A Connection object is implicitly created and set to the Record object when the record is opened with an absolute URL

A Connection object may explicitly be set to the Record object by using the ActiveConnection property The files and directories accessible using the Connection object define the context in which record operations can occur Data modification and navigation methods on the Record object also accept a

relative URL, which locates a resource using an absolute URL or the

Connection object context as a starting point

Topic Objective

To provide an overview of

the Record object

Lead-in

In this topic, you will learn

about one of the new

objects available in ADO:

Record

Stream

! Represents a Stream of Binary Data or Text

! Used with the Record Object to Access the Contents of a File

An ADO Stream object represents a stream of “bits,” binary data or text In a

tree-structured hierarchy such as a file system or an e-mail system, an ADO

Record object may consist of a binary stream of bits that make up the contents

of the record A Stream object can be used to manipulate fields or records

containing these streams of data

A Stream object can be created in one of three ways:

! From a URL pointing to an object (typically a file) containing binary or text

data This object can be a simple document, a Record object representing a

structured document, or a folder

! By opening the default Stream object associated with a Record object You can obtain the default stream associated with a Record object when the

record is opened

! By explicitly creating an instance of a Stream object These Stream objects

can be used to store data for the purposes of your application Unlike a stream associated with a URL, or the default stream of a record, an instantiated stream has no association with an underlying source

Topic Objective

To provide an overview of

the Stream object

Lead-in

In this topic, you will learn

about another one of the

new objects available in

ADO: Stream

ADO exposes the Cursor Service through the Recordset object as a client-side

cursor This is the easiest way to program for the Cursor Service

Topic Objective

To present features of the

OLE DB Cursor Service

Lead-in

In this topic, you will learn

about the OLE DB Cursor

Service

Data Shaping Service

! Relation-based Hierarchical Rowsets

Relation-based Hierarchical Rowsets

The OLE DB Data Shaping Service allows you to create a relationship between two rowsets retrieved from parent and child tables that have at least one field in common In the illustration in the preceding slide, the Order table is related to the Order Detail table through the cust_id field To set up this type of

relationship, you can use the SHAPE command with a RELATE clause that

identifies the fields that match

Group-based Hierarchies

The Data Shaping Service for OLE DB can also be used to create a group-based

hierarchy from a single rowset The BY clause in the SHAPE command is used

to partition a rowset A parent rowset is constructed in which there is one row for each partition in the child rowset

Topic Objective

To provide an overview of

the Data Shaping OLE DB

provider and the Shape

language

Lead-in

In this topic, you will learn

about the architecture of

Data Shaping and the

Shape language syntax

Using Data Shaping

Creating a hierarchy is a two-step process that requires connection to the Data

Shaping Provider and then uses the SHAPE command

You can also use the Data Shaping provider from ADO When you use Data Shaping from ADO, you must setup an explicit connection to the OLE DB provider, as shown in the following example:

Provider=MSDataShape; data provider=MSDASQL; Driver={SQL Server};Server=xxx; Database=yyy; UID=zzz; PWD=;

You can also create an empty hierarchical rowset that can later be populated with data or reshaped In this case, it is not necessary to connect to a data provider, as shown in the following example:

Provider=MSDataShape; data provider=NONE

AS rsDetail COMPUTE rsDetail, SUM(rsDetail.order_amt)

AS order_amt COUNT(rsDetail)

AS DetailCount

BY cust_id

Issues and Challenges of Data Exchange

! Structural Representation of Data

! Extensibility

! Data Is Separated from Presentation and Process

Business applications rarely exist in a void or are completely self-contained Frequently, a business application needs to interact with other business applications to complete a particular business scenario For example, after a requestor submits a requisition, the requisition must be forwarded to a vendor for fulfillment The transfer of data to other systems can be done on an individual basis, and each time such a need arises a new data transfer protocol can be defined

Over time, it became apparent that a structural representation of data needed to

be defined so that the data, together with its schema, can be passed to another application that would be able to retrieve and use data based on the schema provided

In addition, it is important that the standard for data exchange should be extensible Since application needs change, it is necessary to be able to extend the schema for the data exchange to accommodate new requirements

Finally, the actual data being exchanged should be separated from how it should be represented and the process that will facilitate its use

Topic Objective

To discuss issues related to

data exchange

Lead-in

In this topic, you will learn

about issues related to data

exchange

Hypertext Markup Language (HTML) specifies how to display data in a browser; XML defines the content In HTML you use tags to tell the browser to display data as bold or italic; with XML you only use tags to describe data, such

as city name, temperature, and barometric pressure In XML, you use style sheets such as Extensible Style Language (XSL) and Cascading Style Sheets (CSS) to present the data in a browser XML separates the data from the presentation and the process, enabling you to display and process the data as you wish by applying different style sheets and applications

DTD

With XML, Document Type Definitions (DTDs) can accompany a document, essentially defining the rules of the document, such as which elements are present and the structural relationship between the elements DTDs help to validate the data when the receiving application does not have a built-in description of the incoming data

DOM

With the XML Document Object Model (DOM), you can load and parse XML files, gather information about those files, and navigate and manipulate those files

Topic Objective

To discuss how XML can

provide a solution to data

exchange issues

Lead-in

In this topic, you will learn

about XML as a solution for

the challenges of data

exchange

Schema

A schema is a formal specification of the rules of an XML document, namely the element names, which indicate which elements are allowed in a document and in what combinations

For more information on XML, refer to Course 1905A, Building XML-Based

Web Applications

Active Directory Service Interfaces

Dim UsersObj, UserObj, phone Set UsersObj = GetObject("LDAP://CN=Users, DC=twain,DC=local")

' Put in the Company Telephone Number in All Users For Each UserObj In UsersObj

' if it is a user

If UserObj.Class = "user" Then UserObj.Put "telephoneNumber", "212-555-1212" UserObj.SetInfo

End If Next Set UsersObj = Nothing

Windows 2000 includes an application programming interface (API) set called Active Directory Service Interfaces (ADSI) This should be your primary mechanism for creating and changing objects and schemas within the Active Directory services The interfaces are script-friendly and highly optimized to reduce the number of network round-trips

ADSI is a set of COM interfaces that allow you to access Lightweight Data Access Protocol (LDAP)-compliant directories The ADSI object model is

centered on IADs and IADsContainer interfaces

In the code in the slide, you can see a short example of using ADSI to add a

telephoneNumber attribute to every user object in Active Directory

Active Directory will be covered in more detail in Module 10, “Data Services.”

Topic Objective

To show how you can use

the ADSI API to create and

change objects and

schemas

Lead-in

In this topic, you will learn

about the ADSI API

Demonstration: ADSI

This demonstration includes a Visual Basic application called ADSI The

application finds the names of all users in the domain and allows you to modify any user’s description

To run this demonstration, execute the following steps:

! Modify the computer name

1 On the Start menu, point to Programs, then point to Microsoft Visual Studio 6.0, and then click Microsoft Visual Basic 6.0

2 In the install folder\Democode\Mod08\ADSI folder, open the Visual Basic

project ADSI.vbp

3 In the ADSI project, open the form frmADSI

4 In the Form_Load event, replace the string <your Computer Name> with

your computer name

5 Save the ADSI application

! Test the ADSI Application

1 Run the ADSI application

2 Select the Administrator user name

If you typed the wrong computer name in the previous procedure, the user name list will be empty

3 Click Get Description

4 In the text box, enter a new description, and click Set Description

5 Click Set Default Description

6 Click Get Description The description is set back to the original value

In this demonstration, you

will see how to use ADSI in

a Visual Basic application

Note

! Review the application code

1 In Visual Basic, double click on the form frmADSI

2 Review the code for the sub Form_Load It should look like this:

Private Sub Form_Load() ' Get the machine name computer = "WinNT://<your Computer Name>"

Set con = GetObject(computer) ' Populate the combo box with user names cmbUser.Clear

con.Filter = Array("user") For Each Item In con cmbUser.AddItem Item.Name Next

userID = computer & "/" & cmbUser.Text Set user = GetObject(userID)

txtDescription.Text = user.Description Set user = Nothing

End Sub

4 Exit Visual Basic

# Logical Design of Nontransactional DAL

! Iterator

! Applying the Iterator Pattern

Two design patterns you will encounter frequently in the DAL are Iterator and Composite

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 is also an assembly of other parts Although the Composite design pattern is a structural design pattern, it applies very well to helping organize data Often the Data Shaping Service, discussed earlier in this module, implements the Composite design pattern

Since the Composite structural design pattern has already been presented in a previous module, in this section you will learn about the only remaining behavioral design pattern that applies to the logical design of a nontransactional DAL: Iterator

In this section, you will

review the important logical

design patterns for

nontransactional DAL

Iterator

First() Next() IsDone() CurrentItem() Iterator

ConcreteIterator

CreateIterator() Aggregate

CreateIterator() ConcreteAggregate

Client

The Iterator pattern is used to access elements in a list without exposing their internal structure The following table describes the Iterator design pattern

Pattern element Description

Pattern name Iterator

Problem A collection of objects needs to be traversed in a sequential manner

The internal structure and implementation of the collection and objects must not be exposed Solution Create an aggregate class to represent the collection of objects The aggregate class exposes

methods that deal with managing the collection, such as Append and Remove

Create an iterator class that exposes methods to traverse the collection in the aggregate class

The iterator exposes methods that deal with traversal, such as First, Next, and CurrentItem Use a CreateIterator method in the aggregate class to create iterators This prevents the client

of the iterator from having to be aware of and having to use concrete classes

When to use Any time you have a collection of similar objects that must be accessed one at a time in a

sequential manner, consider using the Iterator pattern

Benefits The client is isolated from the internals of the aggregate and the objects in the collection

Different traversal methods can be used without changing the client

An Iterator can keep track of more than one traversal on the aggregate

Drawbacks The CreateIterator method allocates an Iterator dynamically in C++, requiring the client to

clean up the heap This is error prone because the programmer might forget to delete the Iterator Using the concrete classes allocates from the stack and is less prone to error

When there will not be multiple iterators for an aggregate, it can be inefficient to separate the iterator methods from the aggregate methods Under these circumstances, consider joining the aggregate and iterator classes

In this topic, you will learn

about the application of the

Iterator design pattern to

nontransactional DAL