Linq to SQL VS Entity framework .NET
2010-01-12T18:42:27+01:00
2010-09-06T23:37:41+02:00
2022-07-24T23:52:36+02:00
  • Természetesen fogom emészteni, nagyon mély ismeretre utal amit írtál
    Csinálok is majd pár pilot projectet is kísérletként.

    Az elvet nem tudom teljesen megérteni [még?].
    Egy jól megtervezett adatbázisról nem látom át, hogy miért is kellene elvonatkoztatni mégegyszer. [Na jó, néha a DB logikája kényszer, de tipikusan nem, nálam már az üzleti logika jön az adatbázisból.]

    A DataSet a maga többtáblás, relációs eszközeivel tulajdonképpen az adatbázis általam használt részének leképezése lokálisan.
    Természetesen én ráhúzok a Row fogalomra egy típusos osztályt, és nem típusnélkül érem el a táblákat, hanem a típusos Row "ablakon" keresztül nézem, módosítom valódi típusos propertyket tartalmazó objektumként.
    És ez a típusos Row ablak mintegy View-ként mutatja a fizikailag több táblában tárolt adatokat egyetlen objektumként és mintegy mapelésként írja vissza a valódi tábláka (nem is tárol fizikailag, csak a tábla).

    Ha nem pl. egy web-es alkalmazás 3 tábla, 15 mezős modelljében gondolkodom, hanem akár több száz táblás, táblánként százas nagyságrendű mezővel, akkor egy újabb réteg (elvonatkoztatás) felesleges munkának tűnik.

    De örülnék ha meggyőznétek, hagy haladjak a korral... ha megérdemli. [mint megfontolt, körültekintő konzervatív ]
    Mutasd a teljes hozzászólást!
  • Éles projekten használjuk.
    Igazából az EF4 motor a .NET 4 RTM-ből való, a Feature CTP 4 csak mázat ad az egészhez.
    Ha lehetőség szerint lazán akarom csatolni a business logic-ot és az adatelérést, akkor EF4 esetében ezt a megoldást találtam a legüdvözítőbbnek. Persze lehetne klikkelgetni ész nélkül az EF designerben, oszt POCO template-et alátolni, vagy kikapcsolni a kódgenerálást és kézzel elkészíteni a POCO-kat de még mindig klikkelgetni. Na az entitások darabszámának növekedésével egy raklapnyi 24-es TFT sem lenne elég a designernek.
    Mutasd a teljes hozzászólást!
  • Pontosan nem vágom, hogy mire gondolsz. Eléggé lazán kapcsolódik ez és az a másik téma.
    Van ott EF v1 gyengedégeit bemutató írás, meg DDD ellenző is.
    Kifejtenéd bővebben?
    Mutasd a teljes hozzászólást!
  • Ebben az a feature ctp 4 dolog hangzik elég rosszul.
    Mutasd a teljes hozzászólást!
  • EF4-et már szinte kötelező használni 2010-ben, el kell felejteni a DataSet-eteket és hasonló őskövületeket.

    Ha az ember józan parasztésszel tervezi meg az alkalmazásait, akkor a felhasználótól kapott információk alapján az adott problémát osztályok halmazaként, OO szemléletmóddal fogalmazza meg. Erre modern korunkban a DDD azaz Domain Driven Design buzzwordöt találták ki:
    Domain-driven design - Wikipedia, the free encyclopedia

    Kialakul a Domain Model C# nyelvi leírása.
    Tehát tiszta, jó öreg C# (CLR) objektumokkal, osztályokkal dolgozunk. Azaz POCO-kal:
    Plain Old CLR Object - Wikipedia, the free encyclopedia

    Az Entity Framework 4 vagy tetszőleges más ORM, ezekkel tud igazán jól ellenni.
    Felejtsük el azt, hogy az EF4 designerével heggesztjük össze a modelt, aztán valamit hackolunk belőle. Először elkészítjük a Domain Modelt POCO-kal, majd itt jön a képbe a Code First (Nhibernate esetében fluent api):
    Conventions for Code First
    Productivity Improvements for the Entity Framework
    EF Feature CTP4 Walkthrough: Code First

    Persze ehhez az egészhez kell az EF4 Feature CTP 4:
    EF Feature CTP4 Released!

    Ha így tesz az ember, akkor lesz egy C#-ban leírt mapping definíciója a domain model és az adatbázis között. Sőt még adatbázisscriptet is tud generálni.

    Aztán, hogy egy egységes adatelérési kódod legyen be kell vetni a Repository Pattern-t.
    Pl így:
    Elegant Code >> Entity Framework POCO (EF4): Generic Repository and Unit of Work Prototype

    A Self Tracking Entitiest én nem szeretem, mert keresztbeszab a SOA-nak. Meg különben is nem szeretem ész nélkül beküldeni az adatokat az adatbázisban. Meg különben is CRUD service-eket próbálom kerülni.

    ...

    Így tudsz igazán lazán csatolt, modern architektúrával rendelkező, karbantartható, cserélhető blablabla alkalmazást készíteni.

    Azért az EF esetében észnél kell lenni, hogy TPT vagy TPH legyen az öröklődés. Hol célszerű compiled query-ket használni, stb. Mindeezeket a performancia miatt.

    Bocsi, hogy az írásom nagy része linkekből áll, de ha mindent leírtam volna, akkor könyvfejezetről beszélnénk...
    Mutasd a teljes hozzászólást!
  • Míért?
    Pl. a Framework 2.0 még win98-on is futott, a 3.5-nek viszont minimum XP kell.
    Mutasd a teljes hozzászólást!
  • Észrevettétek, hogy míg VS 2008-ban lehetett, VS 2010 használata esetén nem lehet SQL 2000 adatbázishoz LINQtoSQL adatmodellt létrehozni?

    Emögött milyen megfontolás van? Nem úgy szokás, hogy az újabb szoftververziók a régi verziók lehetőségeit megőrzik?

    Mutasd a teljes hozzászólást!
  • A probléma ott kezdődik hogy simán össze tudsz adni egy stringet és egy számot anélkül hogy bármi problémád lenne. Ami egészen addig nem gáz, amíg az input adataidban számok jönnek.

    De sok olyan elírást is megfog a típusosság amikor Pl. egy függvénynek egy rafactoring során megváltoztatod a paraméterszignatúráját, Pl. egy fuggvényt (string txt, int id) helyett fuggveny(int id, string txt) lesz. Akkor ha egy helyen fordított sorrendben hívódik (vagy esetleg te hívod rossz sorrendben véletlenül) akkor az üzenetet már fordításkor az arcodba kapod. Már persze csak akkor, ha szigorúan típusos a rendszered. Ha nem, akkor csak run-time találkozol vele.
    Mutasd a teljes hozzászólást!
  • Hát LC, eddig még nem akartam beszólni, de ennyi szívás miért hiányzik neked a PHP-ból? Mert hogy a PHP nem típusos (vagy gyengén típusos), azt rengeteg helyen hátrányának veszed.

    Ha ott valami null, akkor az egy üres string, ha nulla, akkor pedig egy nagy nulla és nem üres string. Na most mondjatok egy olyan esetet amikor ez problémát jelent. Vagyis például egy regisztrációnál mikor probléma, hogy valaki nem ad meg semmit, vagy egy üres stringet ad meg?
    Mutasd a teljes hozzászólást!
  • Hát részemről egyelőre (normál, nem túl nagy ügyviteli winform alkalmazásban) nem merem használni az EF-öt.
    Túlságosan elbonyolítaná a dolgokat.
    Sok tábla, sok mező, könnyebb leképezni dataset-be. [Nekem sem tetszik a ms féle typed dataset így sajátot használok helyette, így a dataset már cseppet sem olyan "rémisztő"]
    A datasetnek azért elég komoly infrastrukturája van.

    Mitől lene memoria pazarlóbb a dataset?
    Hja aki az egész adatbázist le kívánja rántani lokálba az bármilyen ORM esetén is képes elbarmolni a dolgokat.

    A Linq2Dataset (kérdezte valaki), nagy szívás nagy táblák esetén.
    De ekkor jön jól a Linq2Sql.

    Pl törzsadatok karbantartására vagy adatkarbantartásra, bizonylatfelvitelre nagyon jó a dataset (a maga több táblás relációs logikájával), meg persze lekérdezések táblában megjelenítésére.

    Adhock adatlekérésekkel tarkított lekérdezésekre/feldolgozására meg bőven elegendó a Linq2Sql.

    Vagyis a vegyes modellre szavazok.
    Mutasd a teljes hozzászólást!
  • Légy oly kedves, szokjál le arról, hogy egy hozzászólást 10-szer szerkesztesz.

    Írd meg egy notepad-ban, olvasd el 3-szor, és ha már nincs mit hozzáírni, akkor küld el.
    Mutasd a teljes hozzászólást!
  • Köszi a sok témátol elkanyarodott értékes hozzászolást is!

    De most visszatérve az alaptémára adott egy indulo adatbázis alapú mondjuk közepes ugyviteli winformos vagy ASP-s project.

    Ki mire szavaz az adatkapcsolati réteget illetően ha ma kéne neki állnia?

    -EF
    -LinqToSql
    -Hagyományos (ADO,dataview,tárolt eljárások,dataset)
    -Egyéb
    -Esetleg kevert megoldás
    pl:összetett lekérdezésekhez szerver oldalu viewek
    inputhoz,egyszerűbb lekérdezésekhez: ef,lnqtosql

    Egyébként mi az előnye ált egy mapping frameworknek a rengeteg szivás mellett ezeken kívül hogy:
    -Nem kell a már többé kevésbé elsajátított SQL-el el annyit dolgozni
    -Objektumként kezelhető az adatbázis, a sok ezzel járo új féle szopással együtt..


    Nekem mielött válaszoltok az jön le a hozzászoláskbol, hogy nem szól egyenlőre kellően nyomós érv egyik db mapping eljárás mellett sem. Tehát a bevállt "hagyományos" módszer a biztos, ha nem is a jó választás.
    És azért mi fejlesztők inkább a bevállt biztos megoldást választjuk mint a kétséges ujjat nem?
    Főleg ha az embernek saját fejlesztésű a régi technológiákra támaszkodó de tutira működő adatelérési osztálya van amivel kellően megszenvedett annak idején.

    Azon kívűl engem nem győzött meg a linqToSql sem EF arról hogy Általánosságban gyorsabb az adatfeldolgozás, talán még az sem kizárt hogy lassabb.
    Mutasd a teljes hozzászólást!
  • Én nem tudok elképzelni olyan kutyaütő programot, ahol ilyen előfordulhat eyáltalán.


    Sajnos pedig van ilyen, pont erre írtam jóval lejjebb, hogy jobban szeretem, ha nullable minden, és nem az alapértelmezett értéket kell vizsgálni validációkor.

    Mutasd a teljes hozzászólást!
  • if (alma == new DateTime(1,1,1))

    Háát, nem szebb az if (alma == default(DateTime))


    Én nem tudok elképzelni olyan kutyaütő programot, ahol ilyen előfordulhat eyáltalán.
    Mutasd a teljes hozzászólást!
  • Én sem állítottam mást. :)
    Mutasd a teljes hozzászólást!
  • Elvileg default(DateTime) == new DateTime().
    Ha jól tudom értéktípusoknál a default() művelet az Activator.CreateInstance<T>-t használja, ami pedig az alapértelmezett konstruktort hívogatja (ami publikus és nincs paramétere).

    Kicsit mintha eltért volna ez a topic az eredeti témától, nem?

    Gaia

    Szerk.: ettől még én is default(DateTime)-ot használok, csak jelzem, hogy van alternatíva.
    Mutasd a teljes hozzászólást!
  • És datetimenál? :D

    if (alma == new DateTime(1,1,1))

    Háát, nem szebb az if (alma == default(DateTime))

    Akkor meg már használom konzisztensen...
    Mutasd a teljes hozzászólást!
  • Még jó, hogy nem engedted! Ez:

    == default(int)

    nálam:

    == 0

    A default kulcsszót nem azért kellett bevezetni, hogy tovább lehessen ragozni az amúgy is jó bonyolult kódot, hanem azért, hogy ha generikus definícióban vagy, akkor nem tudod, hogy egy típusnak mi lesz az alapértelmezése, ott kell a default kulcsszó.
    Mutasd a teljes hozzászólást!
  • Ez nehéz ügy. Az alapból nullable típus sem az igazi, egy int legyen 32 bites, akkor viszont nem igazán van hova tenni a null értéket. Vagy kiválasztasz egy adott értéket neki, vagy plusz egy bit de egyik sem igazán jó megoldás. Az egyik nem lesz kompatibilis az int-tel, a másik meg zabálja a helyet. És mindenképpen több erőforrás.

    Másrészt viszont ha ügyvitelt programozol akkor eléggé nagy szívásforrás lehet a nullable-nem nullable kérdése.

    És a ? helyett nem volt már valami normálisabb karakter a billetnyűzeten a tervezők előtt ? Bár köszönjük meg nekik hogy nem a \ jelet használták...

    Amúgy a másik dolog amit rühellek a C#-ban (ha már itt tartunk) hogy ref-nek nem lehet property-t megadni. Na, ez is megért volna a tervezők számára egy nagy sünit...
    Mutasd a teljes hozzászólást!
  • Az csak ilyen s3ggcukor vagy mi. Ha nem tetszik, akkor írd oda, hogy Nullable<int>. Én spec kiütést tudok kapni az olyan C# kódtól, ami olyasmikkel van tele, hogy egy double-t pl System.Double-ként definiálja. Ha van a C#-ban kulcsszó, akkor az kell használni, hogy konzisztens legyen.

    A fordítottja lenne jó inkább. Vagyishogy a referenciatípusokon is lenne olyan megszorítás, hogy lehet-e vagy nem lehet-e null. Ez simán lehetne complier szinten ellenőrizni, a Contract statikus checker is tudja. Plusz, hogy a témánál maradjunk, pl az EF is tudna belőle profitálni, mert így nyelvi szinten ki lehetne kötni, hogy egy-egy csatolt entitás nem lehet null, és akkor nem exception-ök jönnének mentéskor, hanem compiler üzenetek már fordításkor.
    Mutasd a teljes hozzászólást!


  • Amúgy egyetértek veled, jó lenne, ha alapból nullable lenne minden. Tavaly év végén volt egy projekt, ahol harcolnom kellett érte egy másik fejlesztővel, de nem engedtem, hogy mindent úgy vizsgáljunk, hogy == default(int).
    Ha alapból nullable lenne minden, nem lenne gond.

    A másik kedvencem a datetime. Először nem nullable volt minden, aztán persze jött a gányolás kliensoldalon, adtak neki 3999.12.31, meg stb értékeket... Aztán lerendeztem, és nullable lett a legtöbb helyen :D
    Mutasd a teljes hozzászólást!
  • Ez az int? dolog akkor is elég ocsmány. Úgy néz ki mintha megsérült volna a forráskódot tartalmazó fájl.
    Mutasd a teljes hozzászólást!
  • Meg amikor az orm eszköz az int not null oszlopot is Nullable<int>-re mappolná... Szép élet is lenne. Mennék is jávázni egyből.

    Morzel
    Mutasd a teljes hozzászólást!
  • Ígyvan.
    Mutasd a teljes hozzászólást!
  • LC ez nem lenne jó gondold el ha típus szinten nem lenne felülröl kompatibilis a framework milyen galibákat okoznapl meglévő projektek migrálása során...
    Mutasd a teljes hozzászólást!
  • Akkor viszont nem alapértelmezetté kellett volna tenni a C# 4.0-ban a nullable mezőtípust ? És nem int? című szutykokat leírni...
    Mutasd a teljes hozzászólást!
  • Én is a nullable oszlopok mellett vagyok :)
    Mutasd a teljes hozzászólást!
  • Aztán meg kerreg a db, ha le akarod kérdezni az infókat, mert egy oszlop helyett 2-ből jön elő az információ, 2 index scan kell 1 helyett. CUD-nél meg +1 indexet kell írni. Nem nagyon jó.

    Jó az a null, jó az a Nullable<T> (aminek mellesleg korrekt aritmetikája van a C# 2.0 spec.-ben, az operátorok is eszerint működnek, én nem cak adateléréshez, hanem egyéb kódokhoz is használom). Az egyetlen bugyuta dolog az volt, hogy a 2.0-s DataSet valami elmebeteg ötlettől vezérelve nem támogatja a nullázható értékeket. Ez szívás, főleg, ha valami WPF szerű dologba kell bekötni egy DataSet-et.

    Egy ORM zokszó nélkül kezeli a nullázható értékeket.
    Mutasd a teljes hozzászólást!
  • Hát sztem pont az a szeméttel történő telepakolás, hogy most csak ezért felveszel egy másik oszlopot, hogy van-e értéke egy másik mezőnek, tehát lesz egy IsGyerekekSzamaMegVanEAdva meződ, meg egy GyerekekSzama meződ?
    Nem az az egyértelműbb, hogy nincs értéke a GyerekekSzama mezőnek?
    Mutasd a teljes hozzászólást!
abcd