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.

Von Haus aus bringt das Entity Framework keine erweiterte Cache-Funktionalität mit. Wer für Projekte solche Szenarien benötigt, kann aber auf die EFProviderWrappers zurückgreifen. In früheren Beiträgen habe ich aus diesem Toolkit der Möglichkeiten des EFTracingProviders beschrieben. Vor allem gefällt mir hier, dass ich das generierte SQL an spezifische Vorstellungen anpassen kann. Es gibt DBA's die sind in dieser Hinsicht wenig kompromissbereit.

Es lassen sich durch dieses Toolkit auch eigene Provider realisieren.

Mit dem EFCachingProvider besteht die Möglichkeit, dem Entity Framework einen 2nd-Level Cache zu verpassen. So kann es auch weiter zu NHibernate aufschliessen.

Cachevarianten die zur Verfügung stehen sind:

• InMemoryCache (einfache Variante, die nicht sehr leistungsfähig ist)
• Der ASP.NET Cache
• und Velocity (AppFabric)

Gerade mit Velocity steht dann ein sehr mächtiges Caching zur Verfügung. Haufig werden jedoch Probleme mit dem Caching berichtet, wenn View-Generation benutzt wird, da dass Caching mit den Hashes nicht umgehen kann. Dieses Phänomen konnte ich nicht reproduzieren, es liegt evtl. daran, dass ich diese Views mittels T4 und dem zur Verfügungen stehenden EntityViewGenerator erstellen lasse.

Mit der CachingPolicy besteht zudem die Möglichkeit, dass ich definieren kann, ob einzelne Entitäten oder alle zwischengespeichert werden sollen, es ist jedoch nicht möglich, eine Art "partitioniertes" Caching auf einzelne Entitäten eines Sets zu definieren.

Damit das Caching funktioniert, muss der entsprechende Wrapper um die normale Verbindung "gewickelt" werden, das geschieht beim Konstruktor mit folgender Helperklasse:

Provider-Wrapper C#
public ORMSamplesEntities()
            : base(EntityConnectionWrapperUtils.CreateEntityConnectionWithWrappers(
                        ConnectionString,
                        "EFTracingProvider",
                        "EFCachingProvider"
                ), ContainerName)
        {
            Initialize();
        }

In diesem Szenario wird die Verbindung mit dem Tracing- und Caching-Provider umhüllt. In meinem Context habe ich zudem 2 statische Eigenschaften angelegt, die den Zugriff auf die Einstellungen an die Basisklasse weiterleiten:

Eigenschaften für die Cache-Initialisierung C#
public static ICache DefaultCache
{
  get
  {
    return EFCachingProviderConfiguration.DefaultCache;
  }
    		
  set
  {
    EFCachingProviderConfiguration.DefaultCache = value;
  }
}    	
    	
public static CachingPolicy DefaultCachingPolicy
{
  get
  {
    return EFCachingProviderConfiguration.DefaultCachingPolicy;
  }
    		
  set
  {
    EFCachingProviderConfiguration.DefaultCachingPolicy = value;
  }
}

Ein interessantes Detail, diese Eigenschaften müssen vor der Erstellung einer Instanz des Kontexts gesetzt werden, da mit diesen Angaben die Wrapper in den Konstruktoren gefüttert werden.

Machen wir ein kleines Testbeispiel mithilfe des SQL-Profilers und einem Unit-Test. Es soll 4-mal die gleiche Order geladen werden. Mit den Standardmöglichkeiten des Entity Frameworks wird dann die gleiche Abfrage 4-mal an den Datenbankserver gesendet.

Test ohne Cache C#
    [TestMethod]
    public void NonCachingProviderTest()
    {
      // Arrange
      var ctx = new ORMSamplesEntities();

      // Act
      var result = (from o in ctx.Orders.Include("OrderItems")
                   where o.Id == 1
                   select o).ToList();
      
      var result2 = (from o in ctx.Orders.Include("OrderItems")
                     where o.Id == 1
                     select o).ToList();

      var result3 = (from o in ctx.Orders.Include("OrderItems")
                     where o.Id == 1
                     select o).ToList();

      var result4 = (from o in ctx.Orders.Include("OrderItems")
                     where o.Id == 1
                     select o).ToList();
    
      // Assert
      // see Sql-Profiler log ;-)
    }

Führen wir den Test erneut aus, diesmal jedoch mit aktivierten 2nd-Level Cache und dem InMemory-Cache.

Test mit Cache C#
    [TestMethod]
    public void CachingProviderInMemoryTest()
    {
      ORMSamplesEntities.DefaultCache = new InMemoryCache();
      ORMSamplesEntities.DefaultCachingPolicy = CachingPolicy.CacheAll;

      // Arrange
      var ctx = new ORMSamplesEntities();

      // Act
      var result = (from o in ctx.Orders.Include("OrderItems")
                    where o.Id == 1
                    select o).ToList();

      var result2 = (from o in ctx.Orders.Include("OrderItems")
                     where o.Id == 1
                     select o).ToList();

      var result3 = (from o in ctx.Orders.Include("OrderItems")
                     where o.Id == 1
                     select o).ToList();

      var result4 = (from o in ctx.Orders.Include("OrderItems")
                     where o.Id == 1
                     select o).ToList();

      InMemoryCache cache = ORMSamplesEntities.DefaultCache as InMemoryCache;
      // Assert
      Assert.AreEqual(3, cache.CacheHits);
      Assert.AreEqual(1, cache.CacheMisses);
      Assert.AreEqual(0, cache.CacheItemInvalidations);
      Assert.AreEqual(1, cache.CacheItemAdds);

      // see Sql-Profiler log
    }

Die Provider-Wrapper sind nicht nur ein "nettes Spielzeug", sondern auch sehr hilfreich, da diese fehlende Funktionalitäten für das Entity Framework bereitstellen.

Ich gehe stark davon aus, das mit der nächsten Version - ich rede hier jetzt nicht von der EF CTP 4 - diese Funktionalitäten fester Bestandteil des Entity Frameworks werden.

Hier soll jetzt die Aufgabe darin bestehen, zu allen Bestellungen die Anzahl der Bestellpositionen und das Total zu ermitteln.

Die Linq-Abfrage dazu:

C# (Linq)
var resultList = from o in ctx.Orders.Include("OrderItems")
                        select new
                        {
                          Id = o.Id,
                          AnzahlItems = o.OrderItems.Count,
                          Total = o.OrderItems.Sum(s => s.Price * s.Quantity)
                        };

Für diese Abfrage wird folgendes SQL-Statement erstellt:

SQL (EF-Generiert)
SELECT 
[Project1].[Id] AS [Id], 
[Project1].[C1] AS [C1], 
(SELECT 
	SUM([Filter2].[A1]) AS [A1]
	FROM ( SELECT 
		[Extent3].[Price] * [Extent3].[Quantity] AS [A1]
		FROM [QuerySchema].[OrderItem] AS [Extent3]
		WHERE [Project1].[Id] = [Extent3].[OrderId]
	)  AS [Filter2]) AS [C2] -- Sub-Select
FROM ( SELECT 
	[Extent1].[Id] AS [Id], 
	(SELECT 
		COUNT(1) AS [A1]
		FROM [QuerySchema].[OrderItem] AS [Extent2]
		WHERE [Extent1].[Id] = [Extent2].[OrderId]) AS [C1]
	FROM [QuerySchema].[Order] AS [Extent1]
)  AS [Project1]

Dieses Statement verwendet ein Sub-Select für die Bildung der Summe für das Total. Handgeschrieben könnte es in etwa so aussehen:

SQL
SELECT
    o.Id
    , COUNT(oi.Id) as C1 -- AnzahlItems
    , SUM(oi.Price * oi.Quantity) as C2 --Total
FROM QuerySchema.[Order] o
INNER JOIN QuerySchema.OrderItem oi ON oi.OrderId = o.Id
GROUP BY
o.Id

Mit dem EFTracingProvider wird es möglich, das SQL auszutauschen. So kann mithilfe eines Dictionary das bestehende SQL durch das effizientere ersetzt werden. Quasi kann so das Query Rewrite simuliert werden.

In diesem Beispiel kann im Kontext des Event CommandExecuting abonniert werden. Der Codeausschnitt dafür sieht so aus:

C# (Codeausschnitt)
   [TestMethod]
    public void ChangeGeneratedSqlTest()
    {
      // Arrange
      string fileContent;
      string efGeneratedSqlString;
      var ctx = new ORMSamplesEntities();
      ctx.CommandExecuting += ctx_CommandExecuting;
      
      this.queryRewriteSqlString = @"SELECT
	            o.Id
	            , COUNT(oi.Id) as C1 -- AnzahlItems
	            , SUM(oi.Price * oi.Quantity) as C2 --Total
            FROM QuerySchema.[Order] o
            INNER JOIN QuerySchema.OrderItem oi ON oi.OrderId = o.Id
            GROUP BY
            o.Id";

      // Act
      // ctx_CommandExecuting
      var resultList = from o in ctx.Orders.Include("OrderItems")
                        select new
                        {
                          Id = o.Id,
                          AnzahlItems = o.OrderItems.Count,
                          Total = o.OrderItems.Sum(s => s.Price * s.Quantity)
                        };

      efGeneratedSqlString = (resultList as ObjectQuery).ToTraceString();
      // ctx_CommandExecuting
      resultList.ToList();

      fileContent = File.ReadAllText(this.filePath);

      // Assert
      Assert.IsTrue(fileContent.Contains(this.queryRewriteSqlString));
      Assert.IsFalse(fileContent.Contains(efGeneratedSqlString));
      ctx.Dispose();
    }

    private void ctx_CommandExecuting(object sender, CommandExecutionEventArgs e)
    {
      e.Command.CommandText = this.queryRewriteSqlString;
    }

Mit diesem Event sind aber auch andere Szenarien denkbar.

Ein Hinweis zum Schluss, dieses Beispiel rechtfertigt in meinen Augen nicht unbedingt, das SQL zu ersetzen, es soll nur die Möglichkeit des simulierten Query Rewrites mit dem EFTracingProvider aufzeigen. Zum Einsatz kann es auch bei kompromisslosen Richtlinien kommen, zum Beispiel wenn in einer OLTP-Umgebung der Einsatz von Sub-Selects nicht erlaubt ist. Dann ist diese Variante effizienter als der Austausch des O/R-Mappers in einem fortgeschrittenen Projektstatus, nur wegen ein paar einzelner Statements.

Alternativ kann dafür aber auch ExecuteStoreQuery bzw. eine gespeicherte Prozedur verwendet werden. Es muss jedoch dabei berücksichtigt werden, dass diese beiden Varianten nicht mit dem Laden der Objekthierarchien klarkommen und durch das Nachladen das Select N+1-Problem auftreten kann.

Query Rewrite ist eigentlich eine Funktionalität von Oracle in Verbindung mit materialisierten Sichten. Mit dem SQL-Server funktioniert das in Verbindung mit indexierten Sichten nur, wenn die Enterprise- oder Developer-Version verwendet wird.

Die Funktionsweise ist denkbar einfach, wenn eine Anwendung Code mit vielen Joins an die Datenbank sendet, kann mit Hilfe einer materialsierten/indexierten Sicht diese optimiert werden. Der Vorteil dieses Features, es können Optimierungen vorgenommen werden, ohne den Code der zugrunde liegenden Applikation anpassen zu müssen.

Am Beispiel eines TPT-Szenarios probiere ich aus, wie sich Query Rewrite mit dem Entity Framework nutzen lässt. Dazu zuerst eine handgeschriebene SQL-Abfrage.

SQL 
SELECT     
	ProductTPT.Product.ProductId
	, ProductTPT.Product.Name
	, ProductTPT.Product.Description
	, ProductTPT.Book.ISBN10
	, ProductTPT.Book.ISBN13
	, ProductTPT.Book.LanguageCd
	, ProductTPT.Book.Pages
	, ProductTPT.EBook.EBookId
	, ProductTPT.EBook.Filename
FROM ProductTPT.Product 
INNER JOIN ProductTPT.Book ON ProductTPT.Product.ProductId = ProductTPT.Book.BookId 
INNER JOIN ProductTPT.EBook ON ProductTPT.Book.BookId = ProductTPT.EBook.EBookId

Es kann Situationen geben, da führen Join-Abfragen aus der Anwendung heraus zu Performanzeinbussen. Bei Standard-Software besteht dann häufig das Problem, dass diese Abfragen innerhalb der Anwendung nicht optimiert werden können. Hier greift ein DBA häufig auf indexierte Sichten zurück.

Beim SQL-Server muss dazu eine Sicht mit Schemabinding und ein passender gruppierter Index angelegt werden.

SQL (Indexierte View)
CREATE VIEW [dbo].[vwEBook]
WITH SCHEMABINDING
AS
SELECT     
	ProductTPT.Product.ProductId
	, ProductTPT.Product.Name
	, ProductTPT.Product.Description
	, ProductTPT.Book.ISBN10
	, ProductTPT.Book.ISBN13
	, ProductTPT.Book.LanguageCd
	, ProductTPT.Book.Pages
	, ProductTPT.EBook.EBookId
	, ProductTPT.EBook.Filename
FROM ProductTPT.Product 
INNER JOIN ProductTPT.Book ON ProductTPT.Product.ProductId = ProductTPT.Book.BookId 
INNER JOIN ProductTPT.EBook ON ProductTPT.Book.BookId = ProductTPT.EBook.EBookId

Mit diesem Ausflug ist Query Rewrite erklärt. Es gibt aber auch Grenzen dieser Funktionalität, diese werden schnell bei Abfragen mit Inline-Views erreicht, so wie es das Entity Framework auch fabriziert. Betrachten wir nun, was für SQL das Entity Framework an die Datenbank sendet.

Die Abfrage in der Anwendung

C# (Linq-Abfrage)
var ebookList = ctx.Products.OfType<EBook>().ToList();

führt zu folgender SQL-Abfrage:

SQL (Entity Framework)
SELECT 
'0X0X0X' AS [C1], 
[Extent1].[EBookId] AS [EBookId], 
[Extent2].[Name] AS [Name], 
[Extent2].[Description] AS [Description], 
[Extent3].[ISBN10] AS [ISBN10], 
[Extent3].[ISBN13] AS [ISBN13], 
[Extent3].[LanguageCd] AS [LanguageCd], 
[Extent3].[Pages] AS [Pages], 
[Extent1].[Filename] AS [Filename]
FROM   [ProductTPT].[EBook] AS [Extent1]
INNER JOIN [ProductTPT].[Product] AS [Extent2] ON [Extent1].[EBookId] = [Extent2].[ProductId]
INNER JOIN [ProductTPT].[Book] AS [Extent3] ON [Extent1].[EBookId] = [Extent3].[BookId]

Der Unterschied, die Spalte C1 erzeugt zusätzlich einen Compute Scalar-Task, der jedoch keine Kosten verursacht. Der Optimizer merkt, dass er mit der indexierten Sicht die Anfrage viel schneller abarbeiten kann und verwendet diese.

Dieses Beispiel verdeutlicht, dass auch die Datenbank selbst gute Dienste bei der Optimierung leisten kann, sie müssen nur genutzt werden.

Es ist Handarbeit angesagt. Bei den abstrakten Basisklassen müssen nun die Diskriminator-Bedingungen gelöscht werden, damit das Modell fehlerfrei validiert wird. Mit dieser Korrektur ist das Modell einsatzbereit.

Was ich an diesen Workflow nachteilig finde, sind folgende Punkte:

• Die Eigenschaften in Hardcover und EBook müssen auf Nullable = true gesetzt werden. Der Workflow ist nicht in der Lage für die Einstellungen Nullable = false die notwendigen Constraints zu erzeugen.
• Wird in der Klasse wie zum Beispiel Hardcover oder EBook eine Identitätsspalte angelegt, ergibt das keine Fehlermeldung bei der Validierung. Erst bei der Skriptausführung kommt es zu Fehlern.
• Die Diskriminator-Spalten werden nicht normalisiert, möchte man diese auf Ebene der Datenbank verwenden, hat man mit Lösch- und Einfügeanomalien zu kämpfen.
• Die Diskriminator-Spalte ist standardmässig nvarchar(4000).

Ich werde das Entity Designer Database Generation Power Pack im Auge behalten, evtl. kommen hier die Anpassungen in einer späteren Version. Zurzeit überzeugt es mich jedoch nocht nicht.