WCF SOA: CRUD Data Access Service ... warum stören (oder ist unser Design falsch)?

Question

Wir haben einen Datenzugriffsdienst in unserem SOA WCF-System. Dieser Dienst ist verantwortlich für das Ausführen von CRUD-Operationen (Erstellen, Aktualisieren, Löschen) in "systemweiten" Datenbanktabellen und ist auch die Quelle dieser Daten für Abfragen. Jeder andere Dienst im System, der auf die Tabellen unter der Kontrolle des DAS zugreifen möchte, muss zum DAS gehen, um es zu bekommen oder zu modifizieren. Wir verwenden Entity Framework und haben für diesen DAS unser eigenes POCO-Statusverfolgungssystem aufgebaut.

Wir haben andere Tabellen in unserer Datenbank, die zu einzelnen Diensten gehören und Daten nur für ihren eigenen Gebrauch speichern, dh Zustandsinformationen, auf die sie zugreifen können, wenn sie abstürzen und Geschäftsinformationen wiederaufnehmen oder aufzeichnen. Wir haben eine Regel, dass auf eine Tabelle nicht von mehr als einem Dienst zugegriffen werden kann: Daten, die von mehreren Diensten benötigt werden, landen daher im DAS.

Die Wahrheit ist, ich habe nie wirklich verstanden, warum ein Datenzugriffsdienst eine gute Idee ist, im Gegensatz zum direkten Zugriff auf Tabellen. Es scheint langsamer zu sein, unser DAS ist nicht transaktional, da es kein POCO-Diagramm zur Datenbankaktualisierung zurücksenden kann (nur einzelne POCOS gleichzeitig) und wir haben auch Probleme, wo das DAS tatsächlich ein Client für einen anderen Dienst ist, der Daten benötigt daraus ... Kreisabhängigkeit.

Warum sich mit einem DAS beschäftigen? Warum ist ein DAS so wichtig, wenn es um SOA geht? Was fehlt mir hier? Einzelner Kontrollpunkt?

Ist es auch ein SOA-Designfehler, dass nicht alle Tabellen Teil eines DAS sind und dass einige Dienste ihre eigenen "privaten" Tabellen haben?

Jede Diskussion über diese Begrüßung.

Answer 1

Sie haben recht, wenn Sie denken, dass dies der richtige Weg ist, um Dinge zu tun, und Sie haben auch Recht, dass es die Dinge verlangsamt und manchmal mühsam sein kann. SOA konkurriert notwendigerweise mit einer gewissen Effizienz, um einzelne Kontrollpunkte für alle mit einem Dienst verbundenen Daten sicherzustellen. In der Tat ist selbst die Idee, einen "gemeinsamen DAS" -Dienst zu haben, in einigen SOA-Kreisen leicht unangenehm.

Durch die Zentralisierung aller CRUD-Vorgänge auf einen Dienst in einer SOA-Anwendung können Sie die Datenintegrität sicherstellen und sicherstellen, dass Geschäftsregeln ordnungsgemäß verarbeitet werden. Um ein Beispiel zu geben, denken Sie an eine Entität, die Sie speichern möchten und der einige Geschäftsregeln zugeordnet sind, die aus reiner SQL-Perspektive nur schwer zu erreichen sind. Nehmen wir zum Beispiel eine Tabelle, in der Dateiverweise gespeichert und erstellt/aktualisiert werden Dienste, die sicherstellen, dass diese Dateien existieren.

Mit SOA und einem einzigen Zugriffspunkt auf diese Tabellen können Sie die Logik in die Erstellungs-/Aktualisierungsmethoden codieren und sicher sein, dass die Daten, die Sie vom Dienst erhalten, gültig sind - also die referenzierten Dateien vorhanden sind. Wenn irgendjemand in der Lage wäre, in diese Tabellen zu schreiben oder Daten von ihnen abzurufen, gibt es keine solche Zusicherung - selbst wenn Sie den Dienst selbst aufrufen, wissen Sie nicht, was andere Programmierer durch Bosheit oder Planvergessenheit vergessen haben zu implementieren diese kritische Geschäftsregel. Dies führt zu einer defensiven Programmierung, bei der jedes Bit des Client-Codes die Geschäftslogik unabhängig voneinander gewährleistet und letztendlich ein Wirrwarr von Geschäftslogik, die in Ihrer gesamten Anwendung verstreut ist.

Ein weiterer Vorteil ist die Skalierbarkeit und Wartungsfreundlichkeit. Angenommen, einer Ihrer Dienste greift auf einen großen Datenblock zu. Mit SOA ist alles "Black-Boxed", so dass Ihr Client-Code nicht viel Wissen darüber hat, wie die Daten letztendlich erhalten werden. Sie können Ihr RDBMS, Ihre Partitionstabellen oder das Zwischenspeichern ändern und alles für den aufrufenden Client-Code unsichtbar machen - damit Ihre schmerzhaften Aktualisierungen nur an einer Stelle vorgenommen werden müssen. Wenn der Datenbankcode in Ihrer App verstreut ist, wird diese Art von Upgrade extrem schmerzhaft.