Creating a DotNetNuke Private Assembly with Crystal Reports - Part 2
page 1 of 1
Published: 15 Nov 2005
Unedited - Community Contributed
Abstract
This is the second in a series of articles showing how to integrate a Crystal Report Manager into DotNetNuke. This article will step through creating a DAL (Data Access Layer) and BLL (Business Logic Layer) using DNN standards.
by Eric Landes
Feedback
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 28644/ 24

Introduction

As mentioned in Part 1 of this series, DotNetNuke is a great Open Source Portal tool that many in the ASP.NET world use. Please refer to Part 1 for more information about DotNetNuke. For Part 2, we will walk through using the DotNetNuke Data Access architecture for our application.

We will work step by step through setting up the Data Access Layer (DAL) and the Business Logic Layer (BLL) and then integrating those layers with an administrative program to allow adding reports, editing reports, and deleting reports from the Report Manager interface. Later, we’ll show how to set up the code allowing the Crystal Reports to be displayed through this assembly also.

System Requirements

I created this project using Visual Studio 2003, DotNetNuke 3.1.1, SQL Server 2000 and Crystal Reports 10, Windows XP SP2.

Creating the DAL

Download Source

In Visual Studio, we use the entire DotNetNuke project. Others may recommend limiting the number of projects in the solution in order to make debugging easier. For purposes of this article, I am keeping the setup uncomplicated.

For more information on the exact construction of the DotNetNuke data access concepts, open the document “DotNetNuke Data Access” found in the documentation folder of your DNN project. Any time we want to utilize the DNN data access, we must implement methods contained in DNN’s DataAccessProvider class. According to the documentation, data access methods should be SELECT, INSERT, DELETE, or UPDATE SQL statements. Any of the more complex methods such as branching, calculations, and local variables should be implemented in our BLL.

In practical terms, in the CrystalReportManager project, we must create an abstract class called DataProvider. This class contains the abstract methods Select, Insert, Delete, and Update functions. See Code Listing 1 for an example of this.

Code Listing 1

public abstract class DataProvider

{

  public abstract int AddReport(Int32 ModuleId,

    String ReportName, String ReportDescription,

    String FilePath, DateTime DateAdded);

 

  public abstract void DeleteReport(Int32 ReportID);

 

  public abstract IDataReader GetReport(Int32 ReportID, int ModuleId);

 

  public abstract IDataReader GetReports(int ModuleId);

 

  public abstract void UpdateReport(Int32 ReportID, Int32 ModuleId,

    String ReportName, String ReportDescription,

    String FilePath, DateTime DateAdded);

}

Once we have created a DataProvider abstract class, DotNetNuke provides a pattern that utilizes a provider for this class. This provider is specific to the database used. In this case we use SQL Server.

We create a separate project that contains the provider that implements the DataProvider class. In this case, I created a project under the CrystalReportManager folder. Following the pattern of other DesktopModules, that project is under the Providers\DataProviders\SQLDataProvider folder (see below).

Image 1

The Project (called Lancor.CrystalReportManager.SQLDataProvider) contains one class named SQLDataProvider. This project references the project directly under the DesktopModules directory (Lancor.CrystalReportManager) for access to the DataProvider class. In the SQLDataProvider class, the actual SQL Statements go here. DotNetNuke guidelines recommend using stored procedures for our SQL Statements, as I do for almost all applications. DotNetNuke also utilizes Microsoft’s Data Access Application Blocks to facilitate the connection back to the database.

The code to populate our object does not take up much room. For instance, to update your data, the code looks similar to Code Listing 2:

Code Listing 2

public override void UpdateReport(Int32 ReportId,

  Int32 PortalId, String ReportName, String ReportDescription,

  String FilePath, DateTime DateAdded)

{

  SqlHelper.ExecuteNonQuery(ConnectionString,

    DatabaseOwner + "p_lc_Updatelancor_ReportList",

    ReportId, PortalId, ReportName, GetNull(ReportDescription),

    FilePath, GetNull(DateAdded));

}

DotNetNuke recently introduced this DAL concept. In this concept, the DAL passes data back to the BLL using a DataReader. In practice this is accomplished by combining a controller class and and a DataProvider class. The Info class will be explained when we go over the BLL in the next section. For now we have created the DataProvider as the basis of our DAL.

If you are creating unit tests for this class, keep in mind that DNN populates the connection string directly from a web.config key. This makes creating unit tests for DNN pretty difficult but not impossible. You can utilize nunitasp to help with this process along with nUnit. Or, just forget about these frameworks and build your own simplistic unit testing within a web user control. A complete description of the building of these unit tests is beyond the scope of this part of the article.

Now that we’ve created the Data Access Layer, let’s look at some business logic!

Creating the BLL for Crystal Report Manager

Let’s create the Business Logic Layer (BLL) for this assembly. Besides a quick walkthrough of basic DotNetNuke BLL basics, our BLL includes Crystal Specific methods.

DotNetNuke utilizes ArrayLists for the BLL objects’ representation from a data source. The DNN framework providers a Custom Business Objects helper to assist in populating the object. Now that I have the DataProvider created, I want to create the basics of my BLL class. Code Listing 3 contains the code for this object.

Code Listing 3

public class ReportManagerInfo

{

  #region Declarations

  private Int32 _reportID;

  private Int32 _portalId;

  private String _reportName;

  private String _reportDescription;

  private String _filePath;

  private DateTime _dateAdded;

  #endregion

 

  public ReportManagerInfo()

  {

  }

 

  #region Properties

  public Int32 ReportID

  {

    get { return _reportID; }

    set { _reportID = value; }

  }

  public Int32 PortalId

  {

    get { return _portalId; }

    set { _portalId = value; }

  }

  public String ReportName

  {

    get { return _reportName; }

    set { _reportName = value; }

  }

  public String ReportDescription

  {

    get { return _reportDescription; }

    set { _reportDescription = value; }

  }

  public String FilePath

  {

    get { return _filePath; }

    set { _filePath = value; }

  }

  public DateTime DateAdded

  {

    get { return _dateAdded; }

    set { _dateAdded = value; }

  }

  #endregion

}

ReportManagerInfo object is a simple object. Currently there are no methods to add to this object, but there could be. ReportController uses this object as the basis for the arraylist that gets returned when the code calls for the object.

 

In Part 3 of this series, the Crystal Methods get implemented on this object. For now, let’s put what we’ve learned all together.

Creating the Crystal Report Manager Admin module

Now let’s use this DAL and BLL to add records and bind them to a DataGrid. To do this, simply start out by creating an object with a reference to the controller class. Use this class to do the work in the application.

This Administration module allows a user to add records to the system. After using the Admin module, we use the Crystal Parameter information to display the reports. To get a reference to a report in your DNN portal, this module uses a DataGrid for adding, editing and updating that information.

To update, we use code similar to the AddReport method. See Code Listing 4 for a sample of how to use the update method. Simply map the cells in the DataGrid to your object, then call the UpdateReport method in the controller to update your data.

Code Listing 4

public void dg_Update(Object sender, DataGridCommandEventArgs e)

{

  try

  {

    Lancor.CrystalReportManager.ReportsController oReportController =

      new ReportsController();

    Lancor.CrystalReportManager.ReportManagerInfo oReportManager =

      new ReportManagerInfo();

    PortalSettings oPortal = new PortalSettings();

    oReportManager.DateAdded = System.Convert.ToDateTime(e.Item.Cells[4].Text);

    oReportManager.FilePath = e.Item.Cells[3].Text;

    oReportManager.PortalId = oPortal.PortalId;

    oReportManager.ReportDescription = e.Item.Cells[2].Text;

    oReportManager.ReportName = e.Item.Cells[1].Text;

    oReportController.UpdateReport(oReportManager);

    BindGrid();

  }

  catch (Exception ex)

  {

    lblError.Text = ex.Message;

  }

}

If you are familiar with standard DataGrid updating methods, this method should look familiar to you. We use oReportManager as the BLL object. Then oReportController is the ReportsController object. Using the cells in the DataGrid, we set the oReportManagers properties, which oReportController uses to do the update.

Summary

We’ve created the DAL layer and part of the BLL layer of our CrystalReportManager. DNN provides the raw material for creating the DAL and BLL layers, but we do have work to do here. To utilize the stock properties, we needed to define the object properties, Then the stored procedures to do the heavy lifting for our DAL layer.

In the next part of the series we will add the Crystal Parameters to our BLL. Until then, keep on coding!



User Comments

Title: I can't download source code   
Name: Hose
Date: 1/11/2006 9:11:29 AM
Comment:
I can't download source code. :(




Community Advice: ASP | SQL | XML | Regular Expressions | Windows


©Copyright 1998-2014 ASPAlliance.com  |  Page Processed at 8/21/2014 6:08:44 AM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search