Sitze gerade an einer Implementierung eines benutzerdefinierten MembershipProviders. Eigentlich nicht das erste Mal – Verweis auf System.Configuration und System.Web und es kann mit der Realisierung begonnen werden, aber in .NET 4.0 gibt es eine kleine Änderung. Die Basisklasse ist nicht mehr in der Assembly System.Web. Neu wird ein Verweis auf die Assembly System.Web.ApplicationServices benötigt, damit die abstrakte Basisklasse MembershipProvider verwendet werden kann.

Für ein paar Beispiele möchte ich die Code Contracts intensiver nutzen, damit ich eine bessere Routine bekomme. Das erste Mal stand ich an, als ich Argumente einer Methode auf null prüfen wollte, um im positiven Fall eine entsprechende Exception zu erzeugen.

Bisher war mein Ansatz so:

C# (throw Exception) 
public virtual void Add (T entity)
{
    If (entity == null)
    {
        throw new ArgumentNullException("entity", "The parameter entity is null.") ;
    }
    …
}

Zukünftig soll es bei mir so aussehen:

 C# (Contract)
public virtual void Add (T entity)
{
    Contract.Requires<ArgumentNullException>(entity != null, "The parameter entity is null");
    …
}

Damit diese Fehlermeldung nun nicht mehr erscheint, muss in der Projektmappe, welche die Contract-Definitionen enthält der Assembly Mode auf "Standard Contract Requries" und die Checkbox "Perform Runtime Contract Checking" auf "FULL" gesetzt werden. Mit dieser Anpassung ist der Fehler behoben.

Ab ASP.NET 4.0 besteht nun die Möglichkeit, in diesen Validierungsprozess einzugreifen. Mithilfe der AntiXSS-Library kann so bspw. auf sicheres HTML geprüft werden, dieses zu erlauben und alles andere zu verwerfen und den Verarbeitungsprozess zu beenden. Der Vorteil, die Verarbeitung wird nur noch abgebrochen, wenn die Eingabe HTML enthält, das nicht durch die Prüfung der AntiXSS-Komponente kommt.

Dazu muss von der Klasse RequestValidator abgeleitet und die Methode IsValidRequestString überschreiben werden.

C#
namespace RequestValidation
{
  using System;
  using System.Web;
  using System.Web.Util;
  using Microsoft.Security.Application;

  public class SafeHtmlRequestValidator : RequestValidator
  {
    protected override bool IsValidRequestString(System.Web.HttpContext context, 
        string value, 
        RequestValidationSource requestValidationSource, 
        string collectionKey, 
        out int validationFailureIndex)
    {
      validationFailureIndex = 0;

      if (requestValidationSource == RequestValidationSource.Form)
      {
        if (IsSafeHtmlString(value))
        {
          return true;
        }
      }

      return base.IsValidRequestString(context, 
                 value, 
                 requestValidationSource, 
                 collectionKey, 
                 out validationFailureIndex);
    }

    private static bool IsSafeHtmlString(string value)
    {
      string value1 = HttpUtility.HtmlDecode(AntiXss.GetSafeHtmlFragment(value));
      return value1 == value;
    }
  }
}

Anschliessend wird dieser in der web.config mit Hilfe des httpRuntime-Elements registriert.

web.config
<system.web>
  <httpRuntime requestValidationType="RequestValidation.SafeHtmlRequestValidator"/>
---

Die generierten SQL-Statements in EF1 sind häufig ein Reizthema. Das Problem mit dem IN-Statement habe ich bereits erwähnt, aber das allein ist nicht das Problem. Ein häufiges Beispiel für Optimierungen sind die kompilierten Abfragen, die aber auf das generierte SQL keinen Einfluss haben. Was zum Teil für unterhaltsame Abfragen im EF1 generiert werden, ist in diesem Blogbeitrag ersichtlich.

In meinen Beispiel ist die Klasse ModelGenerationExtension von Bedeutung. Die anderen Beispielklassen entferne ich aus dem Projekt. Damit diese auch fehlerfrei kompiliert, muss der Inhalt aus der Beispielmethode AddProperty entfernt werden. Der Einstieg erfolgt über die Ereignismethoden OnAfterModelGenerated und OnAfterModelUpdated. Ich habe es noch nicht mit FxCop getestet, aber der Namensbestandteil After ist gemäss den .NET Framework Richtlinien nicht gerne gesehen ;-)

C# Ereignismethode
        public void OnAfterModelUpdated(UpdateModelExtensionContext context)
        {
            //
            // context.OriginalDocument = The original XDocument before the Update Model Wizard started.
            //                            An extension cannot modify this document.
            //
            // context.GeneratedDocument = The temporary XDocument that was generated by the Update Model wizard from the database.
            //                             An extension cannot modify this document.
            //
            // context.UpdateModelDocument = The contents of context.OriginalDocument merged with the contents of context.GeneratedDocument.
            //                               An extension cannot modify this document.
            //
            // context.CurrentDocument = The XDocument that will be saved.
            //                           An extension can modify this document. Note that the document may have been modified by another extension's implementation of OnAfterModelUpdated().
            //
            //
            // context.ProjectItem = The EnvDTE.ProjectItem of current .edmx file.
            //
            // context.Project = The EnvDTE.Project that contains the .edmx file.
            //
            // context.WizardKind = The wizard that initiated the .edmx file generation or update process (WizardKind.UpdateModel).
            //

            bool efV2Model = IsEntityFrameworkV2Model(context.Project);
            String caption = "OnAfterModelGenerated called";
            String message = String.Format("An EF v{0} model was updated from the database by the 'Update Model From Database' wizard.\n\n", efV2Model ? 2 : 1);

            if (efV2Model)
            {
                // Call helper method to add a new property to the generated EF v2 model.
                AddPropertyToModel(context.CurrentDocument);

                message += "Added a new property to EntityTypes in the updated model.";
            }

            MessageBox.Show(message, caption);
        }

Die Möglichkeiten sind sehr schön in den Methoden dokumentiert, sodass eigentlich gleich programmiert werden kann. Die Edmx-Datei wird als XDocument übergeben. Damit besteht die Möglichkeit, das Modell mit Hilfe von Linq to XML abzufragen.

Szenario

Eine der häufig anzutreffenden Richtlinien auf Datenbankebene ist der Einsatz von Präfixen auf Tabellen-, Sicht- und Spaltennamen. Auf dieser Ebene gibt es wiederum mehrere Varianten. Eine Variante, die sich wunderbar mit diesem Extension Kit eliminieren lässt, ist die ungarische Notationsform. Bei dieser Notation werden die Datentypen als Präfix der Spalte vorangestellt. Im Klassendesign (siehe Abbildung 2) ist so eine Notationsform in meinen Augen nicht zu gebrauchen und das manuelle Anpassen des Modells ist zeitaufwendig und nicht erstrebenswert.

Für diesen Zweck habe ich bereits Klassen erstellt, auf die ich nicht näher eingehe. Die Aufgabe dieser Klassen sind das Abfragen und Bearbeiten des Dokuments. In der Klasse ModelGenerationExtension füge ich dafür eine neue Methode ein, die später von den Ereignismethoden aufgerufen wird.

 C# (Aufruf Methode)
private void ConvertNameAttributes(XDocument model)
{
  var converter = new EfNameConverter();
  converter.PrefixPropertyDescriptions = "lng;str;dbl;dtm";
  converter.PrefixEntityDescriptions = "tab;vw;";
  converter.ReplaceContentList.Add(new Tuple("bit", "Is"));
  converter.ReplaceContentList.Add(new Tuple("AutoID", "Id"));
  converter.ConvertEdmxDocument(model);
}

In dieser Methode wird eine Instanz einer benutzerdefinierten Klasse erzeugt und die Präfixe der Tabellen, Sichten und Spaltennamen definiert. Sonderfälle können mit der ReplaceContentList behandelt werden. So ist es beispielsweise möglich, dass der Präfix bit für bool durch ein „Is“ ersetzt werden kann, damit bitActive in IsActive umgewandelt wird. Auch Namensbestandteile wie AutoID können so in besser klingende Namen umgewandelt werden.

Der Aufruf erfolgt in den Ereignismethoden wie folgt:

C# Aufruf für Ereignismethoden
this.ConvertNameAttributes(context.CurrentDocument);

Wenn ich das Entity Developer Studio mit dem ADO.NET Entity Data Model Extension Starter Kit vergleiche, ist es in dieser Situation mächtiger, weil es mir viel mehr Möglichkeiten eröffnet.

In Projekten bei denen die Richtlinien der Datenbank im Bereich der Namen mit denen der .NET Framework Richtlinien sehr stark in Konflikt stehen, ist diese Erweiterungsmöglichkeit eine optimale Lösung um das Problem elegant zu beheben.