Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 45 trang
THÔNG TIN TÀI LIỆU
Thông tin cơ bản
Định dạng
Số trang
45
Dung lượng
763,91 KB
Nội dung
Public Overrides Sub UpdateEvent(ByVal ItemId As Integer, _ ByVal Description As String, ByVal DateTime As Date, _ ByVal Title As String, ByVal ExpireDate As Date, _ ByVal UserName As String, ByVal Every As Integer, _ ByVal Period As String, ByVal IconFile As String, _ ByVal AltText As String) SqlHelper.ExecuteNonQuery(ConnectionString, DatabaseOwner & _ ObjectQualifier & “UpdateEvent”, ItemId, Description, _ DateTime, Title, GetNull(ExpireDate), UserName, _ GetNull(Every), GetNull(Period), GetNull(IconFile), _ GetNull(AltText)) End Sub #End Region You can see there is a one-to-one relationship within this class, so each method has a corresponding stored procedure within your SQL database. So let’s break down a method here and explain what is happening. We’ll use the GetEvents method. Each event is a public method that overrides a corresponding method within the base class (DataProvider), which you inherited in the beginning of the class. So not only do you have a corresponding method in this class for each stored procedure, you also have a corresponding method in the base DataProvider class, which is located in the main module project. The method within the base class is an abstracted method that your module only deals with; this enables you to totally separate the physical database interactions from your module assembly. Next you’ll notice that all parameters that the stored procedure accepts are passed to your methods as well. In addition, you then execute the command and pass the database connection information such as the connection string, database owner account, object qualifier, name of the stored procedure, and the parameters it accepts. The method then returns an IDataReader (if appropriate, as in SQL select statements) containing the result set from the database using the SQLHelper.ExecuteReader provided by the Microsoft Data Access Application Block you imported at the beginning of the class. Finally, in order to handle null values returned from the database, DotNetNuke provides the GetNull method. When you create a method for your database, as was done in AddEvent and UpdateEvent in Listing 10-13, you should wrap the parameters with the GetNull method. This will prevent errors from being raised in your Data Provider due to the null values. That’s it for the Data Access Layer. Remember this layer is compiled into its own assembly binary sepa- rate from the module’s main assembly. By maintaining this separation you can easily plug in providers for other databases. In addition, no recompile to your base class is necessary when changing database operations, or when replacing physical providers. Data Abstraction The next part of the module for data operations is the creation of the abstraction class. Remember in the Data Access Layer you created methods that overrode the base class? Well now we need to cover that base class and gain some insight on how you provide an abstraction class for the Events module. 285 Developing Modules: The Database Layer 14_595636 ch10.qxd 5/10/05 9:54 PM Page 285 DataProvider Class You now need to switch over to the main module project (DotNetNuke.Events). In this project we have a class file called DataProvider.vb. This class contains nothing but overridable methods, which you over- rode within your Data Access Layer class in the previous section. The first thing you’ll do within this class is import the necessary namespaces and define your class (see Listing 10-14). You’ll notice you use the MustInherit keyword within your class to specify that this class can only be used as a base class, as it is used in the SQLDataProvider class. Listing 10-14: Creating the Abstraction Class for the Events Module Imports System Imports DotNetNuke Namespace DotNetNuke.Modules.Events Public MustInherit Class DataProvider Next is the Shared and Static region (see Listing 10-15) within the class. When the class is instantiated you call the CreateProvider method. Listing 10-15: Shared/Static Methods in the Data Provider Class of the Events Module #Region “Shared/Static Methods” ‘ singleton reference to the instantiated object Private Shared objProvider As DataProvider = Nothing ‘ constructor Shared Sub New() CreateProvider() End Sub ‘ dynamically create provider Private Shared Sub CreateProvider() objProvider = CType(Framework.Reflection.CreateObject(“data”, _ “DotNetNuke.Modules.Events”, “DotNetNuke.Modules.Events”), _ DataProvider) End Sub ‘ return the provider Public Shared Shadows Function Instance() As DataProvider Return objProvider End Function #End Region 286 Chapter 10 14_595636 ch10.qxd 5/10/05 9:54 PM Page 286 Finally, within the abstraction class you have what provides the abstraction, the abstraction methods (see Listing 10-16). Remember these methods from your SQLDataProvider? Each method contained in this base class has a corresponding method within your Data Access Layer’s class. You’ll notice each method uses the MustOverride keyword to specify that its method will be overridden by the class inheriting the abstraction class. Listing 10-16: The Abstraction Methods in the Data Provider Class of the Events Module #Region “Abstract methods” Public MustOverride Function AddEvent(ByVal ModuleId As Integer, _ ByVal Description As String, ByVal DateTime As Date, _ ByVal Title As String, ByVal ExpireDate As Date, _ ByVal UserName As String, ByVal Every As Integer, _ ByVal Period As String, ByVal IconFile As String, _ ByVal AltText As String) As Integer Public MustOverride Sub DeleteEvent(ByVal ItemID As Integer) Public MustOverride Function GetEvent(ByVal ItemId As Integer, _ ByVal ModuleId As Integer) As IDataReader Public MustOverride Function GetEvents(ByVal ModuleId As Integer) _ As IDataReader Public MustOverride Function GetEventsByDate(ByVal ModuleId As Integer, _ ByVal StartDate As Date, ByVal EndDate As Date) As IDataReader Public MustOverride Sub UpdateEvent(ByVal ItemId As Integer, _ ByVal Description As String, ByVal DateTime As Date, _ ByVal Title As String, ByVal ExpireDate As Date, _ ByVal UserName As String, ByVal Every As Integer, _ ByVal Period As String, ByVal IconFile As String, _ ByVal AltText As String) #End Region End Class End Namespace Now you should see the separation of the module from the physical database. Module development closely mirrors DotNetNuke architecture; all aspects of the application are totally separated from the underlying physical database. Summary This chapter covered the physical database creation all the way to the abstraction class contained in your module project. Here are points to remember when developing your database and data classes for your module: ❑ In addition to a primary key for module records, add a module ID field, because each module instance is assigned a unique module ID by the DotNetNuke framework. ❑ Each stored procedure will have a corresponding method contained within the Data Access Layer. 287 Developing Modules: The Database Layer 14_595636 ch10.qxd 5/10/05 9:54 PM Page 287 288 Chapter 10 ❑ Each physical database provider will be created in its own assembly project in the same name- space as the module. ❑ Each abstraction base class will contain duplicate method names in the Data Access Layer that must be overridden. That’s it for the abstraction class. The next chapter covers the Business Logic Layer (BLL), in which you take the data from your database and create objects that you later bind to your user controls for display. 14_595636 ch10.qxd 5/10/05 9:54 PM Page 288 Developing Modules: Business Logic Layer Previous chapters covered how to create a physical database provider for your module, and how all the methods contained in the provider directly correlate to stored procedures within the database. Once the provider was completed, you created an abstraction class that abstracts the methods contained in the physical database in order to be used by the Business Logic Layer (BLL). In this chapter, you take the database portion and transform the record set into a collection of objects that is provided by the Business Logic Layer within your module. We will continue with concepts that were introduced in Chapter 7 on the DNN architecture, because module architecture mirrors the architecture provided by DNN. The idea here is to totally separate the physical database from the module or application logic that you create. Separating the two enables plug-and-play extensibility when you want to change a database provider. Because the provider is abstracted from the actual business logic, you can use the same code, but different data stores, and since they’re compiled separately, there is no need to recompile the application in order to change database providers. We will now continue this provider architecture to the business logic of the application. Here you create a collection of objects with specific properties that will be exposed to your user layer, which is covered in Chapter 12. Developing the Business Logic Layer Start by opening the Events module project located in the DotNetNuke.DesktopModules solution in the Solutions directory contained off of the root of the .NET Nuke distribution package. Open the solution in Visual Studio .NET 2003 to view the module projects; specifically, the DotNetNuke.Events module project you were working with in the previous chapter. 15_595636 ch11.qxd 5/10/05 9:54 PM Page 289 As you’ll recall, the DataProvider.vb class within this project is the abstraction class, and it contains overridable methods for each method contained in the physical provider class. Now you will take these methods and wrap them with additional classes in order to populate an array of objects with specific properties. Defining the Properties for the Info Class This section covers the EventsInfo.vb class contained in the project folder. This class is what describes your objects for the Events module that will be returned from the database. At the top of the class file, we’ll do our imports as in the following code. Imports System Imports System.Configuration Imports System.Data Following this we have our namespace. For this example, you’ll stay within the DotNetNuke namespace, but if you were creating your own modules separate from DNN, you could use a custom namespace in the form of CompanyName.ModuleName. Namespace DotNetNuke.Modules.Events Listing 11-1 shows the Private Members region at the top of the class. Here you define private variables and their types. These variables will be used to store the values for each property for your class. Listing 11-1: The Private Members Region of the EventInfo Class Public Class EventInfo #Region “Private Members” Private _ItemId As Integer Private _ModuleId As Integer Private _Description As String Private _DateTime As Date Private _Title As String Private _ExpireDate As Date Private _CreatedByUser As String Private _CreatedDate As Date Private _Every As Integer Private _Period As String Private _IconFile As String Private _AltText As String Private _MaxWidth As Integer #End Region Below the Private Members region is the Constructors region (see Listing 11-2). In object-oriented pro- gramming, the constructor is a special method for this class that must be present in order for the object to be instantiated; in the Events module with VB.NET it is New. If you needed to write special initializa- tion code for the EventInfo class, you would do so here in order to ensure the code is executed. 290 Chapter 11 15_595636 ch11.qxd 5/10/05 9:54 PM Page 290 Listing 11-2: The Constructors for the EventInfo Class #Region “Constructors” Public Sub New() End Sub #End Region Next are the public properties of the EventInfo class, which are used to define your object (see Listing 11-3). For example, an event has an ItemID, ModuleID, Description, and other properties. These correspond to the fields contained within the database for this module (see Chapter 10). Listing 11-3: The Public Properties for the EventInfo Class #Region “Properties” Public Property ItemId() As Integer Get Return _ItemId End Get Set(ByVal Value As Integer) _ItemId = Value End Set End Property Public Property ModuleId() As Integer Get Return _ModuleId End Get Set(ByVal Value As Integer) _ModuleId = Value End Set End Property Public Property Description() As String Get Return _Description End Get Set(ByVal Value As String) _Description = Value End Set End Property Public Property DateTime() As Date Get Return _DateTime End Get Set(ByVal Value As Date) _DateTime = Value End Set End Property (continued) 291 Developing Modules: Business Logic Layer 15_595636 ch11.qxd 5/10/05 9:54 PM Page 291 Listing 11-3: (continued) Public Property Title() As String Get Return _Title End Get Set(ByVal Value As String) _Title = Value End Set End Property Public Property ExpireDate() As Date Get Return _ExpireDate End Get Set(ByVal Value As Date) _ExpireDate = Value End Set End Property Public Property CreatedByUser() As String Get Return _CreatedByUser End Get Set(ByVal Value As String) _CreatedByUser = Value End Set End Property Public Property CreatedDate() As Date Get Return _CreatedDate End Get Set(ByVal Value As Date) _CreatedDate = Value End Set End Property Public Property Every() As Integer Get Return _Every End Get Set(ByVal Value As Integer) _Every = Value End Set End Property Public Property Period() As String Get Return _Period End Get Set(ByVal Value As String) _Period = Value End Set End Property 292 Chapter 11 15_595636 ch11.qxd 5/10/05 9:54 PM Page 292 Public Property IconFile() As String Get Return _IconFile End Get Set(ByVal Value As String) _IconFile = Value End Set End Property Public Property AltText() As String Get Return _AltText End Get Set(ByVal Value As String) _AltText = Value End Set End Property Public Property MaxWidth() As Integer Get Return _MaxWidth End Get Set(ByVal Value As Integer) _MaxWidth = Value End Set End Property #End Region End Class End Namespace Notice that each property you expose for your object corresponds to a field name within the Events table in DotNetNuke. Creating Objects Using the Controller Class Now that you have the properties defined for your objects, you need to populate the objects with values from your database. This object population begins with the Controller class. In this case the controller is contained in the EventsController.vb class file in the module project. Let’s open up this file and review its contents. Again, at the top of the file are the library imports: Imports DotNetNuke.Services.Search Imports System Imports System.Configuration Imports System.Data Imports System.XML 293 Developing Modules: Business Logic Layer 15_595636 ch11.qxd 5/10/05 9:54 PM Page 293 Following this you again have to specify your namespace: Namespace DotNetNuke.Modules.Events Next, you implement a couple of interfaces after you define your class (see Listing 11-4). In this module you implement the Entities.Modules.ISearchable and Entities.Modules.IPortable. These are two inter- faces that provide your module with the ability to tie into the search mechanism and the ability to export data from your module and import it into another instance of your module on another page within the portal. We’ll cover these interfaces in more detail later in this chapter. Listing 11-4: Defining the Controller Class for the Events Module Public Class EventController Implements Entities.Modules.ISearchable Implements Entities.Modules.IPortable Listing 11-5 shows the public methods within the Controller class that are used to populate an ArrayList of objects from the record set received from your abstraction class. Listing 11-5: Public Methods of the EventsController Class #Region “Public Methods” Public Sub AddEvent(ByVal objEvent As EventInfo) _ DataProvider.Instance().AddEvent(objEvent.ModuleId, _ objEvent.Description, objEvent.DateTime, objEvent.Title, _ objEvent.ExpireDate, objEvent.CreatedByUser, objEvent.Every, _ objEvent.Period, objEvent.IconFile, objEvent.AltText) End Sub Public Sub DeleteEvent(ByVal ItemID As Integer) DataProvider.Instance().DeleteEvent(ItemID) End Sub Public Function GetEvent(ByVal ItemId As Integer, _ ByVal ModuleId As Integer) As EventInfo Return CType(CBO.FillObject(DataProvider.Instance().GetEvent(ItemId, _ ModuleId), GetType(EventInfo)), EventInfo) End Function Public Function GetEvents(ByVal ModuleId As Integer, _ ByVal StartDate As Date, ByVal EndDate As Date) As ArrayList If (Not Common.Utilities.Null.IsNull(StartDate)) And _ (Not Common.Utilities.Null.IsNull(EndDate)) Then Return _ CBO.FillCollection(DataProvider.Instance().GetEventsByDate(ModuleId, _ StartDate, EndDate), GetType(EventInfo)) Else Return _ CBO.FillCollection(DataProvider.Instance().GetEvents(ModuleId), _ GetType(EventInfo)) End If End Function 294 Chapter 11 15_595636 ch11.qxd 5/10/05 9:54 PM Page 294 [...]... interfaces provided by DotNetNuke You do not have to use these methods, but it is recommended in order to provide a fully functional module that is capable of exposing all the features of DotNetNuke ISearchable Listing 11-6 defines properties of the individual events from your module to be placed in the search catalog of the DotNetNuke index Listing 11-6: Defining Search Items of the Module for DotNetNuke Search... with other modules contained in DotNetNuke, and also eases the process of upgrading for future versions of DotNetNuke Note that the SearchItemInfo class exposes properties for the SearchItem object, similar to the Events class This structure is consistent throughout the DotNetNuke architecture and in module development as well IPortable Another interface provided by DotNetNuke that the Events module... Explicit=”True” Inherits= DotNetNuke. Modules.Events.EditEvents” %> 316 Developing Modules: The Presentation Layer You’ll notice you’re registering several DotNetNuke intrinsic controls You did this with the label control in your Settings class, but now you’re implementing several more in this file Table 12-4 lists the controls provided by DotNetNuke and explains their purpose Table 12-4: DotNetNuke Controls... Settings.ascx.vb file Listing 12-9: Defining the Settings Control for the Events Module Imports DotNetNuke Namespace DotNetNuke. Modules.Events Public MustInherit Class Settings Inherits Entities.Modules.ModuleSettingsBase You can see here you inherit the Entities.Modules.ModuleSettingsBase class This class is provided by DotNetNuke and inherits the PortalModuleBase as discussed earlier (see Table 12-2), but... display events in a list format or a calendar format Listing 12 -8 reviews the user control for this module This file is located in the Events project folder called Settings.ascx Listing 12 -8: The Settings User Control for the Events Module As you can see in Listing 12-12, the EditEvents form consists of several controls Many are ASP.NET controls, such as the linkbutton, textbox, validators, and others In addition to the ASP.NET controls there are several of the DotNetNuke controls covered in Table 12-4 The first control you encounter is the DNN Label control: . Events module. 285 Developing Modules: The Database Layer 14_595636 ch10.qxd 5/10/05 9:54 PM Page 285 DataProvider Class You now need to switch over to the main module project (DotNetNuke. Events) 10-14: Creating the Abstraction Class for the Events Module Imports System Imports DotNetNuke Namespace DotNetNuke. Modules.Events Public MustInherit Class DataProvider Next is the Shared and. CreateProvider() objProvider = CType(Framework.Reflection.CreateObject(“data”, _ DotNetNuke. Modules.Events”, DotNetNuke. Modules.Events”), _ DataProvider) End Sub ‘ return the provider Public Shared