A számítógép-programozásban a vérszegény tárgyköri modell olyan antiminta, ahol a tárgyköri modell nem tartalmaz üzleti logikát, mint számításokat, adatok ellenőrzését, üzleti szabályokat. Vitatott minta, mivel szembemegy az objektumorientált programozás alapelveivel, például az egységbe zárással. Előfordul a szerverorientált architektúrák által befolyásolt rendszerekben, ahol a viselkedés nem vagy csak ritkán utazik. Üzenetküldési vagy csővezeték architektúrák Olyan API-k, mint SOAP vagy REST Architektúrák, mint COM+ vagy Remoting megengedik a viselkedést, de előnyben részesítik az állapot nélküli architektúrákat.
Aki mintaként használja, annak el kell fogadnia azt a következményt, hogy ez egy procedurális minta, még ha objektumokat is használ. Ezáltal a programot már nem lehet objektumorientált módon megérteni.
Áttekintés Elsőként Martin Fowler írta le, aki antimintának tekinti:
Az üzleti logikát külön osztályok tartalmazzák, amelyek a tárgyköri modell állapotát változtatják. Java alkalmazásokban gyakori, amit technológiák is támogatnak, mint az EJB entitás beanek. Ennek megfelelője a .NET-ben a Three-Layered Services Application architektúra, ahol ezeket az objektumokat üzleti beaneknek nevezik, habár ezek tartalmazhatnak üzleti logikát.
A tranzakciós szkript mintáról:
A legtöbb üzleti alkalmazás tranzakciók sorozataként is felfogható. Egy tranzakció olvashat bizonyos módon szervezett információkat, egy másik írhat. A kliens és a szerver között minden interakció tartalmaz bizonyos mennyiségű logikát. Bizonyos esetekben ez az információ csak megjelenik, máskor ellenőrzést és számításokat is tartalmaz. Egy tranzakciós szkript ezt a logikát egyetlen eljárásként szervezi, amiben a hívások közvetlenül az adatbázis felé irányulnak, legfeljebb egy vékony burkoló rétegen keresztül. Minden tranzakciónak meglesz a maga tranzakciós szkriptje, habár a gyakori részfeladatok kiszervezhetők al-eljárásokba.
Fowler Patterns of Enterprise Application Architecture című könyvében megjegyzi, hogy a tranzakciós szkript minta rendben van, ha az alkalmazás egyszerű, és nincs szüksége bonyolult objektumorientált adatbázis-leképező rétegre.
Előnyei A logika és az adatok szétválasztása Egyszerű alkalmazásokban jól működik Állapotmentes logikát eredményez, ami könnyebbé teszi az elosztott skálázást. Nincs szükség bonyolult objektumorientált adatbázisleképező rétegre. Jobb kompatibilitás a leképező és injektáló keretrendszerekkel, amelyek egyszerűen csak tulajdonságokat várnak, mint egy specifikus konstruktort.
Hátrányai A logika nem valósítható meg valódi objektumorientált módon. Az egységbe zárás és az adatelrejtés elveinek megsértése. Szükség van egy szolgáltatásrétegre, ami a logikát tartalmazza. A tárgyköri objektumok sosem tudják garantálni korrektségüket, mivel érvényességük és változásuk logikája máshol van elhelyezve, általában több helyen. Kevésbé kifejező modell. Példa Vérszegény class Box { public int Height { get; set; } public int Width { get; set; } }
Nem vérszegény class Box { public int Height { get; private set; } public int Width { get; private set; }
public Box(int height, int width)
if (height <= 0) { throw new ArgumentOutOfRangeException(nameof(height));
if (width <= 0) { throw new ArgumentOutOfRangeException(nameof(width));
Height = height; Width = width;
public int area()
return Height * Width;
Jegyzetek
Források Anemic Domain Model by Martin Fowler Three-Layered Services Application Application Architecture for .NET: Designing Applications and Services Article on why anemic model may be considered good design Writing Clean Code in ASP.NET How to Avoid Anemic Domain Model
Fordítás
Kategória:Programtervezési minták Kategória:Programozási antiminták