Professional DotNetNuke ASP.NET Portals wrox phần 6 ppt

Finally

If Not dr Is Nothing Then

dr.Close()

End If

End Try

Instead of writing all of that code, the CBO Hydrator can be used to greatly simplify things. The code

snippet in Listing 7-5 does the same thing as the code in Listing 7-4, only it uses the CBO Hydrator.

Listing 7-5: Filling an Object Using the CBO Hydrator

Return CType(CBO.FillObject(DataProvider.Instance().GetFolder(PortalID, _

FolderPath), GetType(Services.FileSystem.FolderInfo)), FolderInfo)

This section covered how Custom Business Objects are used throughout DotNetNuke to create a truly

object-oriented design. The objects provide for type safety and enhance performance by allowing code to

work with disconnected collections rather than with DataReaders, DataTables, or DataSets. Use the CBO

Hydrator whenever possible to reduce the amount of coding and to enhance the maintainability of the

application.

Architectural Overview

The DotNetNuke architecture permits the application tiers to be distributed across two servers: the web

server and the database server, as shown in Figure 7-3. The web server contains the presentation, busi￾ness logic, and data access layers. The database server contains the data layer.

Figure 7-3

Clients

Browser Module

(User Control)

Custom Business

Objects (CBO)

Exception

Management

CBO Controllers

Business Logic

Caching Services

Localization

Event Logging

Personalization

Search

Common Data

Provider

Microsoft SQL

Data Provider

Implementation

Other Data

Provider

Implementation

Data Access Data

Database Server

Skin &

Skin Objects

Containers

Default.aspx

Presentation

Microsoft

SQL Server

Other Data

Store

Web Server

195

DotNetNuke Architecture

11_595636 ch07.qxd 5/10/05 10:03 PM Page 195

Presentation Layer

The presentation layer provides an interface for clients to access the portal application. This layer con￾sists of the following elements:

❑ Web Forms: The primary web form is the Default.aspx. This page is the entry point to the por￾tal. It is responsible for loading the other elements of the presentation layer. You can find

Default.aspx in the root installation directory.

❑ Skins: The Default.aspx web form loads the skin for the page based on the settings for each

page or portal. You can find the base Skin class in /admin/Skins/Skin.vb.

❑ Containers: The Default.aspx web form also loads the containers for the modules based on the

settings for each module, page, and portal. You can find the base Container class in /admin/

Containers/Container.vb.

❑ Module User Controls: Modules will have at least a single user control that is the user interface

for the module. These user controls are loaded by Default.aspx and embedded within the con￾tainers and skin. You can find the module user controls in .ascx files in /DesktopModules/

[module name].

❑ Client-Side Scripts: Several client-side JavaScript files are used by the core user-interface frame￾work. For instance, the /DotNetNuke/controls/SolpartMenu/spmenu.js script file is used by the

SolPartMenu control. Custom modules can include and reference JavaScript files as well. You can

find client-side JavaScript files that are used by the core in the /js folder. Some skins may use

client-side JavaScript and in this case you would find the scripts in the skin’s installation directory.

Any client-side scripts used by modules are located under the module’s installation directory.

Rendering the Presentation

When visiting a DotNetNuke portal, the web form that loads the portal page is Default.aspx. The code￾behind for this page ($AppRoot/Default.aspx.vb) loads the selected skin for the active page. The Skin is

a user control that must inherit from the base class DotNetNuke.UI.Skins.Skin. The Skin class is where

most of the action happens for the presentation layer.

First, the Skin class iterates through all of the modules that are associated with the portal page. Each

module has a container assigned to it; the container is a visual boundary that separates one module from

another. The container can be assigned to affect all modules within the entire portal, all modules within

a specific page, or a single module. The Skin class loads the module’s container and injects the module

control into the container.

Next, the Skin class determines whether the module implements the DotNetNuke.Entities.Modules

.iActionable interface. If it does, the Skin class discovers the actions that the module has defined and

adds them to the container accordingly.

Next, the Skin class adds references to the module’s style sheets to the rendered page. It looks for a file

named module.css in the specific module’s installation directory. If it exists, it adds an HtmlGenericControl

to the page to reference the style sheet for the module.

All of this happens within the Skin class in the Init event as shown in Figure 7-4. The final rendering of

the contents of a module is handled within each module’s event life cycle.

196

Chapter 7

11_595636 ch07.qxd 5/10/05 10:03 PM Page 196

Figure 7-4

Finally, the code-behind ($AppRoot/Default.aspx.vb) renders the appropriate cascading style sheet links

based on the configuration of the portal and its skin. See Chapter 13 for more details on style sheets and

the order they are loaded in.

Business Logic Layer

The business logic layer provides the business logic for all core portal activity. This layer exposes many

services to core and third-party modules. These services include

❑ Localization

❑ Caching

❑ Exception Management

❑ Event Logging

❑ Personalization

Default.aspx

Skin

Load

Modules

CSS StyleSheets Module Info

Module Actions Skin Pane

Container

1. Load Skin 1. Load Skin

2. Load and Render Modules 2. Load and Render Modules

7. Add Module 7. Add Module

CSS Stylesheets CSS Stylesheets

3. Get Module 3. Get Module

Info

5. Inject Module Into 5. Inject Module Into

Container and Container and

Add to Skin Pane Add to Skin Pane

4. Load 4. Load

Container Container

6. Add Module 6. Add Module

Actions Actions

1. Load Skin

2. Load and Render Modules

7. Add Module

CSS Stylesheets

3. Get Module

Info

5. Inject Module Into

Container and

Add to Skin Pane

4. Load

Container

6. Add Module

Actions

197

DotNetNuke Architecture

11_595636 ch07.qxd 5/10/05 10:03 PM Page 197

❑ Search

❑ Installation & Upgrades

❑ Security

The business logic layer is also home to custom business objects that represent most entities that collec￾tively make up the portal. Custom business objects are discussed in more detail later in this chapter. For

now it is important to understand that the fundamental purpose of custom business objects is to store

information about an object.

Data Access Layer

The data access layer provides data services to the business logic layer. This layer allows for data to flow

to and from a data store.

As described earlier in this chapter, the data access layer uses the Provider Model to allow DotNetNuke

to support a wide array of data stores. The data access layer consists of two elements:

❑ Data Provider API: This is an abstract base class that establishes the contract that the implemen￾tation of the API must fulfill.

❑ Implementation of Data Provider API: This class inherits from the Data Provider API class and

fulfills the contract by overriding the necessary members and methods.

The core DotNetNuke release provides a Microsoft SQL Server implementation of the Data

Provider API.

Beginning with the CBO Controller class, the following code snippets show how the Data Provider API

works with the Implementation of the Data Provider API. Listing 7-6 shows how the IDataReader that is

sent into CBO.FillObject is a call to DataProvider.Instance().GetFolder(PortalID, FolderPath).

Listing 7-6: The FolderController.GetFolder Method

Public Function GetFolder(ByVal PortalID As Integer, ByVal FolderPath As String) As

FolderInfo

Return CType(CBO.FillObject(DataProvider.Instance().GetFolder(PortalID, _

FolderPath), GetType(Services.FileSystem.FolderInfo)), FolderInfo)

End Function

Figure 7-5 breaks down each of the elements in this method call.

Figure 7-5

Data

Provider

API

Returns

Instance of the

Implementation

of the Data

Provider API

Method that is required by

the Data Provider API

contract.

DataProvider.Instance().GetFolder(PortalID, FolderPath)

198

Chapter 7

11_595636 ch07.qxd 5/10/05 10:03 PM Page 198