Anmelden

  • Website erstellen mit einer Seite Default.aspx
  • Modul Shell erstellen mit ModulInitializer als Klassenbil.,
    • dieses als Verweis der Website hinzufügen
  • In der Website Verweise hinzufügen
    • Microsoft.Practices.CompositeWeb.dll
    • ...
  • in Web.config
    • compositeWeb.modules
    • securityConfiguration.authorizationProvider

  • Global.asax erstellen

< configSections>
< sectionGroup name="compositeWeb">
< section name="modules"
type="Microsoft.Practices.CompositeWeb.Configuration.ModulesConfigurationSection,
Microsoft.Practices.CompositeWeb"/>
< section name="authorization"
type="Microsoft.Practices.CompositeWeb.Configuration.AuthorizationConfigurationSection,
Microsoft.Practices.CompositeWeb"/>
< /sectionGroup>
< section name="securityConfiguration"
type="Microsoft.Practices.EnterpriseLibrary.Security.Configuration.SecuritySettings,
Microsoft.Practices.EnterpriseLibrary.Security, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null"/>
< /configSections>

< compositeWeb>
< modules>
< module name="Shell" assemblyName="Shell" virtualPath="~/"/>
< /modules>
< /compositeWeb>

< securityConfiguration defaultAuthorizationInstance="RuleProvider" defaultSecurityCacheInstance=""> 

< authorizationProviders>< add type="Microsoft.Practices.EnterpriseLibrary.Security.AuthorizationRuleProvider, Microsoft.Practices.EnterpriseLibrary.Security, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null" name="RuleProvider"> 

< rules>

< add expression="R:AdministrationAdvanced OR R:AdministrationBasic OR R:CustomerBasic OR R:CustomerAdvanced OR R:SalesAdvanced" name="AdminAccountView"/> 

 

< /

< /rules>

 

< /add>

< /authorizationProviders> 

< /securityConfiguration>

 

Allgemeines

CompositeWeb ist ein UI-Framework für Web-Applikationen, welches das Framework einer HttpApplication nochmal erweitert.

  • Erweiterungen der Plattform-Services
    • Authorisierung über EnterpriseLibrary.Security
      • Nutzerautorisierung bezogen auf Actions
      • Verwaltung vnn Membership, Roles, Rules, Actions über Provider
    • Einführung von Modulen
      • unabhängig Implementierungsblöcke, Einbindung in das Web erfolgt zur Laufzeit
      • Verwaltung Modul-Modul und Modul-Service-Abhängigkeiten
      • SiteMap-Verwaltung
  • Aufbau

 

Initialisierung

  • Über WebClientApplication bzw. die abgeleitete Klasse (global.asax) werden während der Abarbeitung jedes HTTP-Request eine Reihe von Services geladen:
    • SessionStateLocatorService
    • HttpContextLocatorService
    • ModuleLoaderService
    • FileCatalogModuleEnumerator
    • AuthorizationService
    • SiteMapBuilderService
    • PermissionsCatalog
    • RolesCatalog
  • diese werden dann angesprochen nach dem laden, um:
    • Root-Container erzeugen
    • Module ermitteln (ProfileCalalog.xml)
    • Module-Assemblies laden
    • ModulBase-Implementierungen laden (mittels ObjectBuilder, eine Art Factory)
      • Module-SiteMap füllen
      • PermissionsCatalog füllen
  • abschließend wird die Seite geladen, Codebehind und das MVP des jeweiligen Moduls (dem die Seite angehört) instanziiert (wenn verwendet)
    • [CreateNew] implizite Erzeugung der MVP-Objekte (mittels ObjectBuilder) CodeBehind->Presenter, Presenter->Controller
    • [ServiceDependency] injeziert einen geladenen Service in ein Objekt bei dessen Erstellung (z.B. bei Erstellung des MVP-Controllers)

Modulaufbau

CompositeWeb-Module bestehen i.d.R. aus Modul-Frontend, Modulimplementation und Modul-Initializer. Modulimplementationen sind unabhängig von der Frontend-Technologie (Website, Windows-Applikation):

  • Bei Websites ist das Modul-Frontend ist Teil eine Website, i.d.R. ein Website-Ordner
    • WebPages (aspx)
      • WebPages definieren den HTML-Content basierend auf ASP-Controls
      • bei Verwendung von Masterpages füllt die WebPage nur PlaceHolders der Masterpage aus:
        • stellt das Layout und Design für mehrere WebPages und mehrere Module bereit
        • enthalten Statusinformationen, Controls in Randbereichen (z.B. Login-Status)
        • definiert PlaceHolders
    • CodeBehind (aspx.cs)
      • Initialisierung der WebPage
      • serverseitige Ereignisbehandlung in der WebPage nach Betätigung von Controls
      • instanziiert die Modulimplementation und stellt Interaktion zwischen WebPage und Modulimplementation
  • Modulimplementation
    • eine oder mehrere Klassen außerhalb CodeBehind, die die Modulfunktion implementiert
  • Modul-Initializer: enthält Grundkonfiguration des Moduls, muss immer bereitgestellt werden
    • legt die SiteMap des Moduls fest und versieht Seiten optional mit erforderlichen Permissions
    • PermissionsCatalog: Auflistung und Bezeichnung der Permissions innerhalb des Moduls
    • Sitemap- und PermissionsCatalog-Services werden bei von ModulBase abgeleiteten Klassen über Modul-Properties injiziert
    • Initialisierung eines PageFlow (optional)

Ressourcen:

Arbeitsweise der SiteMap

  • Einhängung
  • Die CompositeWeb-SiteMap (ModuleSiteMapProvider) unterstütz die Sichtbarmachung der Nodes abhängig von der Autorisierung (Permission) des Nutzers. Es ist aber strengstens zu beachten, dass mit der Sichtbarmachung/ Nichtsichtbarmachung NICHT die Autorisierung sichergestellt ist (eine in der SiteMap nicht sichtbare Seite kann ohne weitere Maßnahmen trotzdem per URL aufgerufen werden).

Die Autorisierung ist deshalb implementativ zu regeln (siehe AuthorizationService). 

  • Warum sind Autorisierung und Sichtbarmachung differnziert zu betrachten:
    • Autorisierung

Implementierungsmuster von Modulen

MVP

Model View Presenter: 

  • Presenter (bei Anwendung des MVP, optionales Klasse)
    • entspricht einer View, Modul kann mehrere Views haben
    • erzeugt und referenziert einen Controller bzw. Modulimplementation
    • Formatierung von Daten in HTML-Elemente, Weiterleitung an CodeBehind über ein Interface
    • leitet Ereignisse an Controller
    • siehe MVP (Link)
  • MVP: erzeugt und referenziert einen Presenter, leitet Ereignisse an Presenter weiter, erhält Aufrufe vom Presenter über ein Interface und stellt Daten in Seite dar (Controls/ PlaceHolders)

PageFlow

  • Ein PageFlow-Modul besteht aus mehreren Seiten, die in einer durch den PageFlow festgelegten Reihenfolge/ Verzweigungsmöglichkeiten durchlaufen werden. Mittels PageFlow kann man Assistenten, Bestätigungen usw. realisieren.
  • Kern des PageFlows ist der Controller, der den Seitenfluss bei Verwendung der steuert. Speicherung von Daten in einem PageFlow kann in einer Session erfolgen.
  • siehe PageFlow-Practice

MVP und Controller sind Implementierungs-Pattern. Dienen der Strukturierung und Testbarkeit. Keine implementatorischen Abhängigkeiten seitens CompositeWeb erkennbar.

Implementierungsmuster von Modulen

Module sind Klassenbibliotheken, die bestimmte Schnittstellen (abstrakte Klassen) des CompositWeb-Frameworks bedienen müssen.

  • Ein Modul erfordert immer einen Modul-Initializer

Funktionalität der Module kann wie folgt implementiert werden:

  • Simple Modul
    • Logik wird komplett in CodeBehinds platziert
  • Standard-Modul:
    • Logik wird in (mehreren) Modulimplementationsklassen außerhalb CodeBehind platziert
  • PageFlow-Modul:
    • es wird ein Controller implementiert der vom CodeBehind instanziiert werden kann
    • Services werden über Injection zu internen Modul-Properties (Injektion)
    • Controller kann auch auf globale Services ohne Injektion zugreifen
  • MVP-Modul:
    • Verwendung von Presenter und Controller
    • mit/ohne Service-Injektion möglich
  • MVP- und PageFlow-Modul
    • Selbstverständlich ist die Kombination der beiden Implementierungsmuster möglich.
   
Top

Wir arbeiten mit Software von http://www.campus21.de.

Verantwortlich für angezeigte Daten ist der Webdomain-Eigentümer laut Impressum.

Suche