Da ich auf meine Anfrage keine Antwort gefunden habe, wie wir mit Silverlight, Entity FrameWork und WCF Ria eine SaaS Architektur umgesetzt bekommen, versuche ich die Problemstellung mal einen Schritt weiter vorne anzusetzen.

Wir sind gerade dabei eine Anwendung auf ein SaaS Modell umzustellen. Stark vereinfacht wird es so sein, dass der Anwender eine Anwendungsmodul mietet und dieses so lange nutzt wie er den Mietpreis entrichtet.

Technisch wird es so sein, dass jeder Anwender mit einem Silverlight 4 Client arbeitet. Im Hintergrund befinden sich 1 bis n Datenbanken (MS SQL Server), wobei immer mehrere Anwender sich eine DB teilen. Innerhalb einer DB befinden je Anwender die Tabellen, also für Anwender A eine Kundentabelle und für Anwender B ebenfalls eines Kundentabelle. Unterschieden werden diese Tabellen durch ein eigenes Datenbankschema je Anwender, d.h. AnwenderA.CustomerTable, AnwenderB.CustomerTable usw.

Wie in meiner anderen Frage schon gesagt, stützen wir uns dabei auf einen Artikel aus dem MSDN, der das Prinzip "Multi-Tenant Data Architecture" mit "Shared Database, Separate Schemas" gut beschreibt.

Nun stellt sich uns die Frage, welche Lösung am geeignetsten ist, den Datenaustausch zwischen Silverlight Client und Datenbank herzustellen.

Bisher dachten wir an eine Lösung mit WCF-RIA und Entity Framework. Allerdings ist der Zugriff auf das Datenbankschema im EF nicht öffentlich und ein nachträgliches Verändern
der .ssdl Dateien nach dem Generieren des DomainContexts erscheint fehleranfällig besonders, wenn man mehrere Hundert Anwender managen muss.

Welche Ideen habt ihr den Datenaustausch nach dem Silverlight Client zur Datenbank herzustellen? GIbt es aus Eurer Sicht andere Bibliotheken und Frameworks, die das einfacher lösen können als EF?

Danke
Dirk

Ich würde auf keinen Fall RIA Services einsetzen.

Ich empfinde die Kopplung zur Datenbank als zu stark. Im Prinzip zieht sich die Datenbank Struktur dann durch die ganze Anwendung.

Datenbank Struktur -> Generierte Datenmodell -> Generierte Entitäten in Silverlight -> GUI

Änderungen in der Datenstruktur werden damit zum Problem. Stattdessen würde ich einen eigenen Service Layer mit normalen WCF Services oder auch Workflow Services einziehen, der eigene Entitäten nutzt und das Mapping zur Datenbank macht.

Damit hast du auch einfachere Möglichkeiten zur Aggregation von Daten, zum Beispiel:

Kundendaten aus eigener Datenbank
Lizenzinformation aus zentraler Datenbank

Natürlich musst du dann wieder Überlegen wie du zum Beispiel Validierung auf der Client Seite machst, aber ich würde immer sowohl im Business Layer als auch in der GUI Validieren. Gerade bei Tiers.
Das hat auch den Vorteil

Unsere Architektur sieht folgendermaßen aus:
Silverlight (MVVM) -> WCF-REST-Services -> BusinessLayer -> DataAccessLayer -> DataBase
Vor 1,5 Jahren hatten wir uns gegen RIA-Services entschieden und bislang nicht bereut.
Im DataAccessLayer werkelt EF. Ein Problem hatte ich mit den Entities. Mit POCO Entities kam ich nicht wirklich klar. Derzeit haben wir Self-Tracking Entities im Einsatz. Nicht untersucht habe ich leider DTOs. Wäre eventuell sehr interessant gewesen, aber dafür blieb keine Zeit mehr.
Da mich das dennoch brennend interessiert, werde ich wohl eine neue Frage zu den Entities eröffnen.

Ich kann Sebastian Stehle nur zustimmen. Finger weg von RIA Services, wenn es dynamisch wird.

Welche Ideen habt ihr den Datenaustausch nach dem Silverlight Client zur Datenbank herzustellen? GIbt es aus Eurer Sicht andere Bibliotheken und Frameworks, die das einfacher lösen können als EF?

Schau dir mal CSLA.NET an.
http://www.lhotka.net/cslanet/

Wenn ich das richtig in Erinnerung habe, ist SaaS einer der standard Architekturmodelle die man mit CSLA.NET und Silverlight umsetzen kann.

Ich würde POCO Entities in zwei Fällen verwenden:

1. Du willst die Entitäten noch für etwas anderes verwenden, zum Beispiel als DTO's für den Service oder als Domain Model.

2. Du möchtest vom Entity Framework unabhängig bleiben und vielleicht mal eine exotische Datenbank verwenden. Da EF wirklich viele DBs unterstütz ist das kaum von Bedeutung denke ich.

Zurück zu 1:

Ich würde meinen Server Teil, also das ganze Fundament aus Service über Business Logik zur Datenbank von zwei Richtungen aufziehen:

a) Von den Daten, die ja schnell aus den Requirements abzuleiten sind.
b) Von dem Service Layer, hier ist was einfaches gefragt, das alle Business Operationen aus den Anforderungen abdeckt.

Die zwei Teile sind meiner Meinung nach am Kritischsten, da Änderungen am meisten Kosten. Bei der Datenbank natürlich die Datenmigration und Teil der Business Logik, beim Service Layer Teil der Business Logik und die Adaption der Silverlight Anwendung.

Um Änderungen relativ isoliert zu halten brauchst du also eh eine Art Mapping. Das kann durch die Business Logik direkt erfolgen oder auch an zwei Stellen von Service Layer zur Business Logik und von der Businss Logik zum Data Layer. Ich tendiere zu letzterem. In diesem Fall sind POCOs im Data Layer relativ unwichtig, da du ja das Mapping eh machen musst. Auch wenn das am Anfang mal 1:1 ist, das kann sich ja noch ändern. Du kannst also dein Datenbank einfach zusammenklicken und dann daraus deine Entitäten generieren.

Das ganze hat natürlich ein Nachteil: Du hast viele gleiche Entitäten und viel Arbeit mit Mapping. Mit ein bisschen Aufwand kannst du dir aber einen Code Generator bauen und am Anfang alles automatisch konsistent halten. Später wirst du das per Hand machen müssen, aber dann kommen ja auch weniger Änderungen.

Das kommt aber auf die Anwendung an. Du kannst natürlich auch einfach Transaction Scripts erstellen.

Du hast die Frage diesmal weiter gefasst als beim letzten Mal, aber wenn ich Dich richtig verstehe, ist die Kernfrage immer noch: wie gestaltet man den Datenzugriff in einer Anwendung, die nach dem "separate schema"-Ansatz mandantenfähig gemacht werden soll?

Viel mehr als in der ersten Runde habe ich dazu nicht zu bieten, aber doch immerhin zwei Links zu verwandten Diskussionen bei stackoverflow:

Multitenant NHibernate application with with separate SQL Server schema for each tenant

What is the best implementation for changing the database schema at runtime using Entity Framework 4?. Hier hat der Fragesteller offenbar selbst eine funktionierende Lösung gefunden, auf deren Beschreibung er verlinkt. Vielleicht hilft Dir das.