Vérszegény tárgyköri modell

A számítógép-programozásban a vérszegény tárgyköri modell tárgyköri modellje nem tartalmaz üzleti logikát, mint számításokat, adatok ellenőrzését, üzleti szabályokat. Vitatott minta, mivel szembemegy az objektumorientáltság 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.

Ennek az antimintának az a horrorja, hogy ellenkezik az objektumorientáltság alapötletével: az egységbe zárással, ami egy helyre csoportosítja az adatokat és a rajtuk végrehajtott műveleteket. Procedurális stílusú, még ha objektumokat is tartalmaz… A Smalltalkban az első napoktól kezdve küzdöttünk ellene. Még rosszabb, hogy sokan úgy gondolják, hogy ezek valódi objektumok, így nem is értik meg, hogy mire való az objektumorientáltság.

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ás ré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;
    }
}

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

Ez a szócikk részben vagy egészben az Anemic domain model című angol Wikipédia-szócikk fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.