Transaktionsgrenzen in einer N-Tier-Architektur

Question

Ich habe eine 3-Tier-Architektur, die in etwa wie folgt aussieht:

Client -> Business -> Daten

Wo sollen Transaktionen starten ideal?

Eine Denkrichtung besagt, dass Transaktionen nur am Anfang der Datenschicht beginnen sollten. Die Business-Schicht manipuliert nur Business-Objekte mit Geschäftslogik und weiß nie über Transaktionen. Das Unternehmen macht alle seine Arbeit, um Objekte zu manipulieren, und übergibt sie dann an die Datenschicht, die persistiert werden soll. Es ist eine etwas REST-orientierte Philosophie, die auf die unteren Schichten angewendet wird.

Eine andere Denkrichtung besagt, dass Transaktionen an der Spitze der Business-Schicht beginnen sollten. Die Business-Schicht definiert logische Arbeitseinheiten, nicht die Datenschicht, da eine logische Arbeitseinheit manchmal Geschäftslogik und nicht nur Datenlogik enthält.

Ich mag die Idee, Transaktionsprobleme so gering wie möglich zu machen. Aber ich finde auch, dass es zusätzliche Anstrengungen und Design-Herausforderungen erfordern kann, um zu versuchen, die Geschäftslogik außerhalb der Datenschicht zu halten, es sei denn, es handelt sich nur um CRUD-Operationen. Wenn Sie RESTful-Entwurfsmuster mit einem Vorschlaghammer anwenden, können Sie es so einrichten, dass Ihre Anwendungen nur sehr wenige Nicht-CRUD-Operationen haben.

Es gibt sogar eine dritte Denkrichtung, die besagt, dass der Client Transaktionen starten kann, damit er mehrere Geschäftsvorgänge bei Bedarf kombinieren kann. Aber jetzt definiert der Kunde die Arbeitseinheit? Ist das nicht ein Geschäftsanliegen?

Eine vierte Schule der Gedanken besagt, dass meine Kunden nur SOA-Komponenten sein können, die an einer XA-Transaktion teilnehmen können, die sogar außerhalb des Clients gestartet wurde !!

Unsere Entwickler möchten einige Standards Beton mehr als nur „Transaktionen starten, wo immer Sie Lust haben“

Hat jemand irgendwelche Meinungen oder Anregungen zu diesem Thema?

Danke!

Answer 1

Transaktion ist ein Geschäftskonzept und sollte innerhalb der Business-Ebene koordiniert werden.

Die isolierte Manipulation von Objekten macht normalerweise wenig Sinn, und die Manipulation zwischen mehreren Objekttypen ist bereits eine Transaktion. Die erste Denkschule beschäftigt sich mit wirklich grundlegenden Fällen.

Wenn Ihre Business Tier Transaktionen abwickelt, spielt es keine Rolle, wer die Transaktion startet: Client oder anderer Service. Lang andauernde (verteilte) Transaktionen können nur unterstützt werden, wenn sie für Business Tier bekannt sind.

Answer 2

Im

Client -> Business -> Daten

Architektur, es ist immer besser, die Transaktion auf der Business-Ebene zu definieren. Ich würde vorschlagen, dass die Transaktion so definiert wird, dass der Geschäftsservice entweder eine neue Transaktion startet oder an der bestehenden Transaktion teilnimmt, wenn eine solche bereits gestartet wurde. Dies kümmert sich um Fälle, in denen ein Business-Service von einem anderen Business-Service aufgerufen wird.

nicht die Transaktionsgrenze an der Datenschicht, wenn die Business-Schicht mit mehreren Datenschichten Anrufe als Teil der gleichen Antrag stellen, wie

client1-> Business1 => data1, Business1 => Daten2