| 

.NET C# Java Javascript Exception

1
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
News:
28.02.2011
ampersand 31 1 4
Vielleicht fast schon off-topic, aber mich würde interessieren, ob ihr oder einer der Antwortenden für dieses Szenario den Einsatz von MS Azure erwogen hat bzw. erwägen würde?
Matthias Hlawatsch 28.02.2011
Ja, wir haben das auf dem Schirm. Die Datenbank unserer Anwendung würde sich durchaus für eine Cloudlösung eignen. Planst Du etwas Ähnliches?
ampersand 28.02.2011
5 Antworten
3
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
28.02.2011
sebastianstehle 444 6
Ich muss mich erstmal in die gesamate Thematik WCF services reinfinden, da wir bisher nur "lokal" waren. Wie stellt denn Silverlight die Verbindung zu einem normalen WCF-Service her? Und ist das auch machbar wenn 100 oder 1000 Anwender auf diesen Service zugreifen?
ampersand 28.02.2011
Z.B. SOAP oder REST. Beides hat Vor- und Nachteile. Ich bervorzuge REST.
REST sind einfache http-Aufrufe. Das heisst, dass die Performance bei gleichzeitigen Zugriffen vergleichbar ist, wie bei einer WebSite.
Jürgen Luhr 28.02.2011
2
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.
28.02.2011
Jürgen Luhr 7,1k 2 9
Wie macht ihr denn das Transaktionshandling, also commit und rollback auf Datensatz/feld-Ebene. Ist das bei den STE's mit "drin"? Kannst Du sagen was Eure Anwendung tut?
ampersand 28.02.2011
Transaktion sind bei STEs nicht drin. Für Transaktionen gibt es mehrere Möglichkeiten. Ich verwende den MSDTC http://msdn.microsoft.com/de-de/library/system.transactions.aspx
Der Inhalt der Anwendung ist hier eher uninteressant. Hier ein paar Eckdaten:
- ca. 350-400 Datenbanktabellen
- sehr serverlastig (Businesslayer)
- Server steht beim Kunden
- Software muss internetfähig sein und im Browser laufen
- nur für einen begrenzten Benutzerbereich (also nicht fürs ganze Internet)
- mehrere 100 User und parallele Zugriffe möglich
Hope that helps ;o)
Jürgen Luhr 28.02.2011
1
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.
28.02.2011
Florian Mätschke 370 1 7
DAnke, das schaue ich mir nochmal an. Hab das mal vor 1 oder 2 Jahren angeschaut im RAhmen lokaler DB-Apps. Wir haben uns damals aber für XPO von DevExpress entschieden, das für lokale Apps sehr gut zu programmieren war. Ob es für Silverlight mit Service Umgebung passt, prüfen wir derzeit.
ampersand 28.02.2011
1
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.
28.02.2011
sebastianstehle 444 6
1
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.
28.02.2011
Matthias Hlawatsch 13,2k 4 9

Stelle deine .net-Frage jetzt!
TOP TECHNOLOGIES CONSULTING GmbH