Anemický model domény - Anemic domain model

Anemický model domény je použití softwaru model domény kde doménové objekty obsahují malé nebo žádné obchodní logika (validace, výpočty, obchodní pravidla atd.).

Přehled

Tento vzor byl poprvé popsán[1] podle Martin Fowler, který považuje praxi za anti-vzor. On říká:

Základní hrůzou tohoto anti-vzoru je, že je tak v rozporu se základní myšlenkou objektově orientovaného navrhování; což je kombinace dat a jejich společné zpracování. Model anemické domény je jen design procedurálního stylu, přesně ten typ věcí, se kterými objektové fanatici jako já ... bojují od našich počátků v Pokec. A co je horší, mnoho lidí si myslí, že anemické objekty jsou skutečné objekty, a tak jim úplně uniká smysl toho, o čem objektově orientovaný design je.

V anemickém návrhu domény je obchodní logika obvykle implementována v samostatných třídách, které transformují stav objektů domény. Fowler volá takové externí třídy transakční skripty. Tento vzor je běžným přístupem v Jáva aplikace, případně podporované technologiemi, jako jsou dřívější verze systému Windows EJB je Fazole entity,[1] stejně jako v .SÍŤ aplikace navazující na třívrstvou aplikační architekturu služeb, kde tyto objekty spadají do kategorie „obchodních entit“ (ačkoli obchodní entity mohou také obsahovat chování).[2]

Fowler popisuje vzor transakčního skriptu takto:

Většina obchodních aplikací může být považována za sérii transakcí. Transakce může zobrazit některé informace uspořádané určitým způsobem, jiná v nich provede změny. Každá interakce mezi klientským systémem a serverovým systémem obsahuje určité množství logiky. V některých případech to může být stejně jednoduché jako zobrazení informací v databázi. U jiných to může zahrnovat mnoho kroků validace a výpočtů. Transakční skript organizuje veškerou tuto logiku primárně jako jeden postup a provádí volání přímo do databáze nebo prostřednictvím tenkého databázového modulu. Každá transakce bude mít svůj vlastní Transaction Script, i když běžné dílčí úkoly lze rozdělit na dílčí postupy.[3]

Ve své knize „Patterns of Enterprise Application Architecture“ Fowler poznamenal, že vzor transakčního skriptu je pro mnoho jednoduchých obchodních aplikací v pořádku, a odstraňuje složitou vrstvu mapování OO-databáze.

Důvody, proč k tomu může dojít

AnemicDomainModel se může objevit v systémech, které jsou ovlivněny architekturami orientovanými na služby, kde chování necestuje nebo má tendenci necestovat.

  • Architektury pro zasílání zpráv / potrubí
  • API, jako je SOAP / REST

Architektury jako COM + a Remoting umožňují chování, ale web stále více upřednostňuje odpojené a bezstavové architektury.

Kritika

Existuje určitá kritika ohledně toho, zda by měl být tento vzor návrhu softwaru považován za anti-vzor, ​​protože mnozí v něm vidí také výhody, například:

  • Jasné oddělení mezi logikou a daty.[4]
  • Funguje dobře pro jednoduché aplikace.
  • Výsledkem je logika bez státní příslušnosti, což usnadňuje škálování.
  • Vyhýbá se potřebě složité vrstvy mapování OO-databáze.
  • Více kompatibility s mapovacími a injektážními rámci, které očekávají hloupé vlastnosti, spíše než konkrétní konstruktor nebo pořadí populace vlastností. [4]

Závazky

  • Logiku nelze implementovat skutečně objektově.
  • Porušení zapouzdření a skrývání informací zásady.
  • Potřebuje samostatnou obchodní vrstvu, která obsahuje logiku, která se jinak nachází v a model domény. To také znamená model domény Objekty nemohou v žádném okamžiku zaručit jejich správnost, protože jejich validační a mutační logika je umístěna někde venku (nejpravděpodobněji na více místech).
  • Vyžaduje vrstvu služeb při sdílení logiky domény mezi různými spotřebiteli objektového modelu.
  • Model je méně výrazný.

Příklad

Anemický

třída Box{    veřejnost int Výška { dostat; soubor; }    veřejnost int Šířka { dostat; soubor; }}

Není anemický

třída Box{    veřejnost int Výška { dostat; }    veřejnost int Šířka { dostat; }    veřejnost Box(int výška, int šířka)    {        -li (výška <= 0) {            házet Nový ArgumentOutOfRangeException(jméno(výška));        }        -li (šířka <= 0) {            házet Nový ArgumentOutOfRangeException(jméno(šířka));        }        Výška = výška;        Šířka = šířka;    }    veřejnost int Plocha()    {        vrátit se Výška * Šířka;    }}

Viz také

Reference

  1. ^ A b http://www.martinfowler.com/bliki/AnemicDomainModel.html
  2. ^ „Archivovaná kopie“. Archivovány od originál dne 10.01.2013. Citováno 2013-02-13.CS1 maint: archivovaná kopie jako titul (odkaz)
  3. ^ https://www.martinfowler.com/eaaCatalog/transactionScript.html
  4. ^ A b http://blog.inf.ed.ac.uk/sapm/2014/02/04/the-anaemic-domain-model-is-no-anti-pattern-its-a-solid-design/

externí odkazy