Transaktionsskript ist Antipattern?

Question

Nun, es gibt ein ähnliches Thema über Transaktions-Skript mit NoSQL-Datenbank, aber dieses hier ist über das Muster im Allgemeinen. Von dem, was ich über Transaction-Skript finde, ist es überhaupt nicht objektorientiert. Sein grundsätzlich prozeduraler Code trotz der Tatsache, dass er Objekte in jeder Zeile seines Codes verwenden kann.

Die bessere Lösung besteht darin, stattdessen ein Domänenmodell zu verwenden, das entweder mit einem aktiven Datensatz oder einem Datenmapper mit Einheit der Arbeits-/Identitätskarte/Lazy Load/Query-Objekt und dergleichen gekoppelt ist. Transaktionsskript kann einfach zu verwenden sein, aber es ist wirklich prozedurale Programmierung und sollte daher in einer objektorientierten Welt als Antipattern betrachtet werden.

Was denkst du? Sind Sie damit einverstanden, dass das Transaktionsskript Antipattern ist? Oder haben Sie tatsächlich eine Möglichkeit, ein Transaktionsskript zu entwickeln, das objektorientiert statt prozedural verkleidet ist? Ich bezweifle jedoch, dass dies möglich ist.

Answer 1

Transaction Script ist definitiv nicht ein Anti-Pattern.

Von was ich über Transaction Skript finde, ist es überhaupt nicht objektorientiert.

Sie haben Recht, es ist nicht, tatsächlich. Diese Tatsache macht es jedoch nicht zu einem Anti-Pattern. Obwohl es sich um einen prozeduralen Ansatz handelt, hat es dennoch seinen richtigen Platz in der Reihe der Business-Logic-Architekturmuster - Sie müssen nur wissen, in welchem ​​Fall es die beste Vorgehensweise ist, es zu verwenden - und in diesem Fall ist es das nicht. Einfach ausgedrückt: Wenn Ihre Problemdomäne sehr einfach ist, lohnt es sich nicht, ein komplexeres Muster in Ihrer Geschäftslogik zu verwenden. Oder

- wie Fowler schreibt:

Wann Verwenden Sie

Die Herrlichkeit des Transaction Script ist seine Einfachheit. Das Organisieren von Logik auf diese Weise ist für Anwendungen mit nur einer kleinen Menge von Logik natürlich, und es beinhaltet sehr wenig Overhead, weder in der Leistung noch im Verständnis.

Das Anti-Muster, an das Sie denken könnten, heißt Anemic Domain Model. Dies ist der Fall, wenn Sie beabsichtigen und denken Sie bauen ein Domain Model - weil Ihre Problemdomäne komplex genug dafür ist, - aber Sie tatsächlich am Ende in einem Transaction Script - wegen schlechten Code-Organisation/schwach OO Fähigkeiten.

Answer 2

Es ist nicht ein Anti-Muster. Tatsächlich verwenden die meisten Unternehmensanwendungen (alles, was ich gesehen habe) Transaktionsskript und kein reiches Domänenmodellmuster.

Aktive Aufzeichnung Muster, das Sie erwähnt ist nur praktisch, wenn man ziemlich einfach 00.59 Zuordnung von Domain-Entitäten zu persistenten Speicher Aggregate (RDBMS Tabellen).

Datenmapper ist so etwas wie ORM (Hibernate und Freunde). Wenn sich Ihre Geschäftslogik in Domänenentitäten befindet, müssen sich diese Entitäten selbst mutieren. Meiner Meinung nach koppelt dies Logik, die den Zustand (der bei Verwendung von ORM inhärent ist) mit dem Zustand selbst mutiert.Es ist einfacher, Ihr Domänenmodell von außen zu betrachten und Ihre Geschäftslogik in Services (Transaktionsskripten) zu integrieren. Wenn Ihr Geschäftslogik-Volume groß ist, ist es außerdem schwieriger, relevanten Code zu finden, wenn dieser über Domain-Entitäten verstreut ist (als wären Ihre Transaktionsskripts gemischt).

Sie müssen jedoch nicht mit einem vollständig prozeduralen Ansatz enden, da Sie Ihre Dienste in eigenständige, stark zusammenhängende "prozedurale Container" zerlegen können (und sollten).