Crud műveletek & entity framework & null object

Crud műveletek & entity framework & null object
2018-06-09T14:56:53+02:00
2018-06-11T09:53:05+02:00
2022-10-15T21:35:38+02:00
7563604
Entity framework adatbázishoz szeretném elkészíteni a szokásos add, remove... műveleteket.
Amikor egy osztállyal szeretnék visszatérni (pl egy building) amit az id-je alapján keresnék meg és ha nem létezik, akkor nem nullal akarok visszatérni, hanem egy null object-el. Szeretnék készíteni pl egy nullable Building osztályt.
Olvastam hogy ilyenkor érdemes singletonként elkészíteni az adott osztályhoz tartozó nullable osztályt.

Tovább gondolva mivel több nullable osztályt szeretnék létrehozni szeretném egy factory tervezési mintával megfűszerezni.

Viszont ilyenkor kellene egy partial osztály is amivel bővítem az entity framework által generált Building osztályt, és felé helyeznék egy interface-t, és nem pedig örököltetnék a Building osztályból.

Tanácsok, ötletek, hogy érdemes-e és esetleg hogy min változtassak?

ui: Egy bónusz kérdés, ha hozzá adok egy adatbázishoz egy felhasználót, és egy int-el azaz az újonnan létrehozott felhasználó id-jával szeretnék vissza térni, de valami hiba történt a művelet során, akkor egy hibakóddal térjek vissza, pl minusz egyel, vagy hogy kezeljem le a try-catch blokk ban? Köszönöm előre is a válaszokat.
Mutasd a teljes hozzászólást!
Senki nem tud jobbat? Hát akkor az én véleményem.

Szerintem nem kell ennyire túlbonyolítani. Egyszerűen hozz létre property inicializálókat mindenhová, ami null lehet (EF code first, ugye?).

Példa:

public string Description { get; set; } = string.Empty;
Utána lekérdezés után adj vissza egy új üres entity-t, valahogy így:

var building = (from c in context.Buildings where c.Id == buildingId select c).SingeOrDefault(); if (building == null) { return new Building(); }
Ez elméletileg némi teljesítménycsökkenéssel jár az inicializálók miatt (főleg, ha sok objektum property van), de a gyakorlatban valószínűleg ez mérhetetlen lesz (a program a hálózatra, adatbázisra, felhasználóra stb. fog várni 90%-ban), míg az előnyei - egyszerűség, átláthatóság, hibabiztosság - kézzelfoghatóak. (Pl. ha bővíted az osztályt, hozzáadod az új property-t az inicializálóval és mindenütt automatikus marad a null object létrehozása.)

Ugyanakkor én DTO-kat használnék, és nem közvetlenül az entity osztályokat a rugalmasság érdekében (akár valamilyen automapperrel). EF ide vagy oda, célszerű elkülöníteni az adatelérést a BL-től. Tehát nem az entity-ken hoznám létre a property inicializálókat, hanem a DTO-kon. (Ráadásul amennyiben az entity objektumon hozod létre az inicializálókat, az adatbázisba íráskor is természetesen azok az értékek lesznek használva, - pl. üres string null helyett -, ami nem feltétlenül kívánatos.)

Bónusz kérdéshez: újabban újra divat kerülni az exception dobást és visszatérni mindenféle furcsa érték visszaadásához (teljesítményre hivatkozva), de egy nem teljesítményre kihegyezett programnál szerintem ez a karbantarthatóságot rontja, ami fontosabb szempont. Szóval szerintem -1-et, egyebeket nem célszerű visszaadni.

Ugyanakkor ha már úgyis a null object pattern-t követed, akkor én a helyedben az egységesség jegyében eleve nem az id-t adnám vissza, hanem a teljes felhasználó objektumot, ami hiba esetén üres lesz (aztán majd a feldolgozás helyén lehet vizsgálni, hogy az ID-je 0-e).

(Szerk.: több magyarázattal kiegészítve a DTO-khoz.)
Mutasd a teljes hozzászólást!

Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd