Categories: Application Blocks, Enterprise Library Posted by AlexanderZeitler on 2/2/2005 10:12 AM | Comments (0)

Die kürzlich veröffentlichte Enterprise Library fasst die bekannten Application Blocks in einer Library zusammen. Da sich zum einen beim Data Access Application Block einiges (um nicht zu sagen alles ;-)) geändert hat, hier eine kurze Einführung in die Handhabung des Data Access Application Blocks nach dem Umstieg auf die Enterprise Library:

Nach der Installation der Enterprise Library, müssen zunächst die neuen Libraries erstellt werden. Hierzu ist die Enterprise Library Solution in Visual Studio.NET zu öffnen:

Nach dem Laden sollte sich die Solution etwa wie folgt präsentieren:

entlibsolutionvs.jpg

Um die Libraries nun zu erstellen, muß zunächst von Debug auf Release umgeschaltet werden...

...um die Projektmappe dann zu "erstellen" (Build):

Der Buildvorgang nimmt einige Zeit in Anspruch, wird dann aber erfolgreich abgeschlossen.

Nun ist es an der Zeit, ein neues Visual Studio.NET ASP.NET Projekt zu beginnen...

...und zwei Verweise auf die notwendigen Enterprise Libraries zu erzeugen:

Benötigt werden "Microsoft.Practices.EnterpriseLibrary.Configuration.dll" sowie "Microsoft.Practices.EnterpriseLibrary.Data.dll":

 

Danach ist die Enterprise Library Configuration zu starten:

Die Configuration präsentiert sich wie folgt:

entlibconfigurationstartscreen.jpg

Nach deren Start ist mittels Rechtsklick der Punkt "New Application" aufzurufen:

Der Name der Application lautet in unserem Fall "AdventureWorks"

Nun ist erneut mittels Rechtsklick der "New Data Access Application Block" hinzuzufügen:

Dieser wird nun hinzugefügt. Doch nicht nur der DAAB wird hinzugefügt, sondern auch der Configuration Application Block, da die Konfiguration des DAAB nun in diesem abgelegt und verwaltet wird:

Nun sind noch die Einstellungen für die Datenbank zu treffen - zunächst der Name des Connection-Strings:

Der Name der Datenbank:

Die Einstellungen für die Integrated Security bleiben unverändert (können aber natürlich auch angepasst werden)

Der Server:

Nun kommt der eigentliche Clou an dem Configuration-Tool: das Speichern der Settings. Nach einem Klick auf den Save-Button öffnet sich der Speichern-Dialog, in welchem wir nun die web.config(!) unserer Application AdventureWorks auswählen:

Die Meldung zum Überschreiben der Web.config können wir bestätigen (nur Mut ;-)).

Die web.config präsentiert sich nun wie folgt:

<?

xml version="1.0" encoding="utf-8"?>

<

configuration>

<configSections>

<section name="enterpriselibrary.configurationSettings" type="Microsoft.Practices.EnterpriseLibrary.Configuration.ConfigurationManagerSectionHandler, Microsoft.Practices.EnterpriseLibrary.Configuration, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />

</configSections>

<system.web>

<!-- DYNAMISCHE DEBUGKOMPILIERUNG

Setzen Sie compilation debug="true", um .SPX-Debuggen zu aktivieren. False

verbessert die Laufzeitleistung der Anwendung.

Setzen Sie compilation debug="true", um Debugsymbole (PDB-Informationen)

in die kompilierte Seite einzufügen. Da hierdurch eine größere Datei erstellt wird,

die langsamer ausgeführt wird, sollten Sie diesen Wert nur zum Debuggen auf True setzen und

ansonsten auf False. Weitere Informationen finden Sie in der Dokumentation über

das Debuggen von ASP.NET-Dateien.

-->

<compilation defaultLanguage="c#" debug="true" />

<!-- BENUTZERDEFINIERTE FEHLERMELDUNGEN

Legen Sie für customErrors mode="On" oder "RemoteOnly" fest, um benutzerdefinierte Fehlermeldungen zu aktivieren, oder "Off", um sie zu deaktivieren.

Fügen Sie für jeden Fehler, der behandelt werden soll, ein <error>-Tag hinzu.

"On" Immer benutzerdefinierte Meldungen anzeigen.

"Off" Immer detaillierte Informationen zu ASP.NET-Fehlern anzeigen.

"RemoteOnly" Benutzerdefinierte Meldungen nur solchen Benutzern anzeigen, die nicht auf

dem lokalen Webserver aktiv sind. Diese Einstellung wird aus Sicherheitsgründen empfohlen,

um zu vermeiden, dass Anwendungsdetails Remoteclients gegenüber angezeigt werden.

-->

<customErrors mode="RemoteOnly" />

<!-- AUTHENTIFIZIERUNG

Dieser Bereich legt die Authentifizierungsrichtlinien für die Anwendung fest. Mögliche Modi sind "Windows",

"Forms", "Passport" und "Keine"

"Keine" Es wird keine Authentifizierung durchgeführt.

"Windows" IIS führt die Authentifizierung durch gemäß den

Einstellungen für die Anwendung (Basis-, Digest- oder integrierte Windows-Authentifizierung). Der anonyme Zugriff muss in IIS deaktiviert werden.

"Forms" Sie stellen ein benutzerdefiniertes Formular bereit (Webseite), in dem die Benutzer ihre Anmeldeinformationen eingeben. Anschließend

werden sie in der Anwendung authentifiziert. Ein Token für die Benutzeranmeldung wird in einem Cookie gespeichert.

"Passport" Die Authentifizierung erfolgt durch einen zentralen Authentifizierungsdienst von

Microsoft, der eine einmalige Anmeldung und wichtige Profildienste für Mitgliedssites bietet.

-->

<authentication mode="Windows" />

<!-- AUTORISIERUNG

Dieser Bereich legt die Autorisierungsrichtlinien der Anwendung fest. Sie können Zugriff auf

Anwendungsressourcen pro Benutzer oder pro Rolle gewähren oder verweigern. Platzhalter: "*" bedeutet alle, "?" steht für anonyme

(nicht authentifizierte) Benutzer.

-->

<authorization>

<allow users="*" />

<!-- Alle Benutzer zulassen -->

<!-- <allow users="[kommabegrenzte Liste von Benutzern]"

roles="[kommabegrenzte Liste von Rollen]"/>

<deny users="[kommabegrenzte Liste von Benutzern]"

roles="[kommabegrenzte Liste von Rollen]"/>

-->

</authorization>

<!-- ABLAUFVERFOLGUNG AUF ANWENDUNGSEBENE

Ablaufverfolgung auf Anwendungsebene aktiviert die Ablaufprotokollausgabe für jede Seite innerhalb der Anwendung.

Die Einstellung trace enabled="true" aktiviert die Ablaufverfolgung der Anwendung. Wenn pageOutput="true", werden

Ablaufverfolgungsinformationen am Ende jeder Seite angezeigt. Andernfalls kann das

Ablaufverfolgungsprotokoll der Anwendung durch Browsen der Seite "trace.axd" vom Stamm der Webanwendung aus

angezeigt werden.

-->

<trace enabled="false" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true" />

<!-- EINSTELLUNGEN FÜR SITZUNGSSTATUS

Standardmäßig verwendet ASP.NET Cookies, um festzustellen, welche Anforderungen zu einer bestimmten Sitzung gehören.

Wenn keine Cookies verfügbar sind, kann eine Sitzung durch das Hinzufügen eines Sitzungsbezeichners zum URL nachverfolgt werden.

Die Einstellung sessionState cookieless="true" deaktiviert Cookies.

-->

<sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="20" />

<!-- GLOBALISIERUNG

Dieser Bereich legt die Globalisierungseinstellungen der Anwendung fest.

-->

<globalization requestEncoding="utf-8" responseEncoding="utf-8" />

</system.web>

<enterpriselibrary.configurationSettings xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" applicationName="AdventureWorks" xmlns="http://www.microsoft.com/practices/enterpriselibrary/08-31-2004/configuration">

<configurationSections>

<configurationSection xsi:type="ReadOnlyConfigurationSectionData" name="dataConfiguration" encrypt="false">

<storageProvider xsi:type="XmlFileStorageProviderData" name="XML File Storage Provider" path="dataConfiguration.config" />

<dataTransformer xsi:type="XmlSerializerTransformerData" name="Xml Serializer Transformer">

<includeTypes />

</dataTransformer>

</configurationSection>

</configurationSections>

<keyAlgorithmStorageProvider xsi:nil="true" />

<includeTypes />

</enterpriselibrary.configurationSettings>

</configuration>

Wie man sieht, hat das Tool die Web.config nicht einfach überschrieben, sondern angepasst. Das beste daran: man kann die Web.config mit dem Configuration Tool wieder laden und erneut anpassen!

Doch nicht nur die Web.config wurde angepasst, sondern auch die Konfiguration für den DAAB in einem eigenen Konfigurationsfile, der dataconfiguration.config, abgelegt.

Diese muss nun zu unserem Visual Studio.NET Projekt "AdventureWorks" hinzugefügt werden:

Damit sind wir bereits fast am Ziel - einzig der Code, um Daten aus der AdventureWorks-Datenbank zu lesen, fehlt noch.

Dieser findet sich in der neu angelegten default.aspx(.cs) und sieht wie folgt aus:

default.aspx:

<%@ Page language="c#" Codebehind="default.aspx.cs" AutoEventWireup="false" Inherits="AdventureWorks._default" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<HTML
lang="en">
<HEAD>

<title>default</title>

<meta name="vs_defaultClientScript" content="JavaScript" >
<meta name="vs_targetSchema" content="http://www.w3.org/1999/xhtml" >
</HEAD>

<body>

<form id="default" method="post" runat="server"><asp:DataGrid id="dgProducts" runat="server" BorderColor="#CC9966" BorderStyle="None" BorderWidth="1px" BackColor="White" CellPadding="4">
<FooterStyle ForeColor="#330099" BackColor="#FFFFCC">
</FooterStyle>

<SelectedItemStyle Font-Bold="True" ForeColor="#663399" BackColor="#FFCC66">
</SelectedItemStyle>

<ItemStyle ForeColor="#330099" BackColor="White">
</ItemStyle>

<HeaderStyle Font-Bold="True" ForeColor="#FFFFCC" BackColor="#990000">
</HeaderStyle>

<PagerStyle HorizontalAlign="Center" ForeColor="#330099" BackColor="#FFFFCC">
</PagerStyle></asp:DataGrid>

</form>

</body>
</HTML>

default.aspx.cs:

using System;
using System.Collections;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Web;
using System.Web.SessionState;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.HtmlControls;

using Microsoft.Practices.EnterpriseLibrary.Data;

namespace AdventureWorks
{
    ///


    /// Zusammenfassung fr _default.
    ///
    public class _default : System.Web.UI.Page
    {
        protected System.Web.UI.WebControls.DataGrid dgProducts;
    
        private void Page_Load(object sender, System.EventArgs e)
        {
            if(!Page.IsPostBack) {
                this.dgProducts.DataSource = GetProducts();
                this.dgProducts.DataBind();
            }
        }

        private DataSet GetProducts() {
            Database db = DatabaseFactory.CreateDatabase();
            DBCommandWrapper dbCommandWrapper = db.GetStoredProcCommandWrapper("GetProducts");
            return db.ExecuteDataSet(dbCommandWrapper);
        }

        #region Vom Web Form-Designer generierter Code
        override protected void OnInit(EventArgs e)
        {
            //
            // CODEGEN: Dieser Aufruf ist fr den ASP.NET Web Form-Designer erforderlich.
            //
            InitializeComponent();
            base.OnInit(e);
        }
        
        ///
        /// Erforderliche Methode fr die Designeruntersttzung.
        /// Der Inhalt der Methode darf nicht mit dem Code-Editor gendert werden.
        ///
        private void InitializeComponent()
        {
            this.Load += new System.EventHandler(this.Page_Load);

        }
        #endregion
    }
}

Interessant ist die Methode GetProducts() welche den eigentlichen DAAB-relevanten Code beinhaltet:

Zunächst erzeugen wir eine Database-Instanz, was bereits die erste Neuerung darstellt (vorher mittels AdoHelper.CreateHelper( assembly, type) relativ umständlich).

In der nächste Zeile erzeugen wir uns einen DBCommandWrapper für eine Stored Procedure. Alternativ könnte hier auch ein DBCommandWrapper für ein SqlCommand erzeugt werden.

Um nun ein DataSet zu erhalten, wird die ExecuteDataSet-Methode der Database mit dem eben erzeugten DBCommandWrapper aufgerufen.

That's it ;-)

Das Resultat:

Hier noch die Stored Procedure für die AdventureWorks DB:

CREATE PROCEDURE [dbo].[GetProducts] AS

SELECT
    ProductNumber, [Name]
FROM
    Product
GO

Comments are closed