LINQ<->DBDesign<->ORM: HOGYAN??
2008-02-19T15:31:32+01:00
2008-03-28T14:03:41+01:00
2022-07-26T01:47:22+02:00
  • A phpMyAdmin lesz a nyerő...
    Mutasd a teljes hozzászólást!
  • Tényleg, akkor minek is szórakozunk Master Data Management szolgáltatások és felhasználói felületek fejlesztésével? SQL Server Management Studio Express vagy phpMyAdmin, oszt jónapot!

    \o/
    Mutasd a teljes hozzászólást!
  • Triggerből is maximum Pistike Bt. fog adatokat validálni, annak örömére, hogy végre a MySQL is tud olyat.

    Mutasd a teljes hozzászólást!
  • Elmúltak már azok az idők, amikor egy önálló adategység (latinul entitás) megegyezett a Microsoft SQL Server x.x verzió egy táblájának sorával. Triggerből is maximum Pistike Bt. fog adatokat validálni, annak örömére, hogy végre a MySQL is tud olyat.

    Most jön az a rész, hogy a LINQ to SQL és az EF akkor tulajdonképpen mé ilyen sz4r disconneted? Holnaptól szeretném, ha a böngészős AJAX felületem JSON-ös, REST-es szórakozás helyett valódi szerverkurzort kapjon!
    Mutasd a teljes hozzászólást!
  • Nem erre céloztam. Azt se értem, miért kellene az egész mindenséget letölteni? Csak a SELECT-et kell úgy megfogalmazni, hogy ne hozzon le mindent, mindjárt piszok gyors lesz, az más, hogy ők nem értenek ehhez, de pont ezt akartam az előbb kihangsúlyozni. Sose használtam úgy a dispécsert se, hogy SELECT * FROM anyámkínjamegamitméghozzágondolsz, kell utána a WHERE ... . Az total működőképes így, gyorsan, csak a T-SQL-t kell ismerni , de még azt se, ha alapból be lenne nekik állítva. Ezt tudom, ezzel most volt is gond, Budapestről már annyi adat van és ezt mindig letöltik, módosítják, újat adnak hozzá, szerencsére visszafele már csak a változásokat küldik fel.
    Mutasd a teljes hozzászólást!
  • Dr. John Microby főprogramozó bácsi észrevesz egy bugot a Live Spaces motorjában, mondjuk az adatvalidáció környékén. Örül, mert nem halmozódó bug, egy sor javít, rebuild DLL. MAJD: rebuild Windows Live Mainframe Monolithic Management Client 33.4534.234, 9.6 gigás ClickOnce deploy frissít. Jövök, elzőző buli képeit raknám a blogomra, 9.6 gigás Windows Live Mainframe Monolithic Management Client 33.4534.233 -> Windows Live Mainframe Monolithic Management Client 33.4534.234 frissítés, anyázás, anyázás ... kép föl. Holnapi buildig rendben is vagyok.

    Melyik része rugalmas ennek??
    Mutasd a teljes hozzászólást!
  • Azt nem mondtam, hogy biztonságos , csak hogy rugalmas.
    Mutasd a teljes hozzászólást!
  • Szép is lenne, hogy ha le kellene töltenem a Microsfottól az egész Live Spaces motorját a Live Writerbe ágyazva, ha fel akarok tenni egy idióta képet magamról a blogomba. Meg majd biztos oda is adnák mindenkinek a kódot, csak úgy barátságból. Ja, természetesen a Redmondi szerverszoba SQL szervereihez is adják vele a connection stringeket, meg minden Live ID-hez minden egy SQL szerverre fel fognak tenni külön felhasználókat a megfelelő jogok beállításával.

    Ez lesz majd a Windows Live Mainframe.
    Mutasd a teljes hozzászólást!
  • Ezt a közvetlenül adatbázishoz kapcsolódó, hipervastag kliensekkel való kemény sz0pás óta tudjuk, hogy messze el kell kerülni, ha egy mód van rá.


    De belső, saját felhasználású managementnek még mindig ez a legrugalmasabb és leggyorsabb megoldás, amíg a licenszhez tartjuk magunkat. Persze ok, hogy ezentúl minden adatbázishoz, amit csinálunk lesz managment felület, amit WCF szolgáltatásokon keresztül elérünk, illetve azt mindenki érteni is fogja, bár ez a diszpécseres megoldás nagyon hatékonynak tűnik még mindig .

    Na mindegy, én most úgyis a WPF-be vagyok teljesen belebolondulva, ez szerintem a három közül a legnagyobb téma, úgyhogy van mit olvasni, meg gyakorolni.
    Mutasd a teljes hozzászólást!
  • Plusz még egy: úgy néz ki hogy Linq to SQL csak microsoft SQL szerverre létezik, és ez így is marad (legalábbis a vistadb fórumain ilyesmit írtak a fejlesztők)
    Mutasd a teljes hozzászólást!
  • Amg a kommunikáció alapját az egyszeri SOAP üzenetek képezik, lényegében teljesen totál mindegy, hogy miben valósítod meg belülről.

    Ami kint van, az arcitektúrális, ami belül, az pedig nagyrészt implementációs kérdés. Az implementációt meg nem tesszük ki a homlokzatra, és főleg nem adjuk ki feladatként a klienseinknek. Ezt a közvetlenül adatbázishoz kapcsolódó, hipervastag kliensekkel való kemény sz0pás óta tudjuk, hogy messze el kell kerülni, ha egy mód van rá.

    ADO.NET SQL Command/Query -> LINQ to SQL -> Entity Framework.

    Elméletileg a sorban előre haladva növekszik a produktivitás, de a Beta 3-ból kiindulva az utolsó lépésnél ezt annyira nem látom. Ha a végleges, SQL 2008-ba épített verzió fogja tudni azokat, amiket 2006-ban kitaláltak, akkor lesz igaz a tendencia. Meglátjuk.

    Ez akkor is implementációs, nem architektúrális réteg. A v1 EDM csak akkor tudna megszorítások nélkül működő Model rétegként funkcionálni, ha minden elképzelhető objektumszerkezet leírható lenne vele. Legyen úgy, de én azért ez kétlem.
    Mutasd a teljes hozzászólást!
  • Véletlen találtam rá ezekre, nem szándékosan akartam megnézni . Csak gondoltam, ha má' ott van, belekukkantok.

    ...hiába lesz kész az EF, dógozni azért kell majd az után is.


    Ezt nem cáfolom. Ez a sok dolog, amit a MS idead még korántsem ment meg a kézgyakorlattól. Sőt, pont ellenkezőleg sült el minden, az UI-t teljesen kézzel kell írnom . Ugyanez igaz az adatkezelésre is, dataset összekattintgatás helyett már lehet normális OO modellben dolgozni, s ahogy mondod Te is, nem elég az EDM designerrel összekattintgatni az egészet, hanem körmölni kell a saját mappinget hozzá. Még több munka vele, mint korábban, de persze előnye is több van.

    A szolgáltatás (SOA) részével én annyira nem vagyok képben, de biztos igazad van. Szerintem (is) tök mindegy, hogy Linq To SQL által, vagy Entity Framework által generált modell, ezeket úgy ahogy vannak kirakni szőröstől, bőröstül ökörség. Közé kell az a réteg, ami szabályozza, hogy milyen adatok mehetnek ki és jöhetnek vissza. Sejtelmem szerint ezt nevezed "szolgáltatás homlokzatnak", ami ugyebár WCF-en keresztül publikálja a felületeket.

    Mindenestre érdekes a téma. A LINQ to SQL-be az tetszik, hogy közvetlenül látom az adatbázis fizikai modelljét és ezen keresztül érem el a dolgokat, míg az EF-be bejön egy fogalmi modell, amiről a mapping gondoskodik nekem, hogy helyesen képződjön le. De, hogy most akkor melyik a jobb? Egyébként a látott teszteken az EF lényegesen gyorsabb volt, mint a LINQ To SQL. Még egy tulajdonság, ami mellette szól.
    Mutasd a teljes hozzászólást!
  • Ahogy én látom az Entity Framework-öt a Beta 3 alapján, még mindig el tudok képzelni rengeteg olyan entitásszerkezetet (a példámban említett is ilyen), aminek nem tudok megfelelő EDM modellt rajzolni. Ilyenkor vagy alkalmazkodok az EDM lehetőségeihez, vagy nem az EDM-et beszélem ki, hanem megy a mapping továbbra is, mint LINQ to SQL-nél. Én még mindig nem vagyok róla meggyőződve, hogy a SOA/MDM forgatókönyv megvalósításához nem a LINQ to SQL lesz továbbra is a nyerő az EF-hez képest. Valami nekem azt súgja, hogy ez így is fog maradni. Ebből az következik, hogy hiába lesz kész az EF, dógozni azért kell majd az után is.

    Nem ezeket a semmit mondó fícsördemókat kell nézni. Abból nem derül ki soha, hogy hogyan is válik be egy-egy technológia egy szolgáltatás mögött.

    Itt van a lényeg: channel9 - Architecture.

    Itt olyan emberek beszélnek, akik láttak már 5 gépet összedrótozva dolgozni.

    Persze vannak az EF ígéretei között olyanok, amiknek a Beta 3-ban még nyomát sem látni. Ha azokat sikerül belerajzolni a nyárig, akkor jön el az a pillanat, hogy ki lehessen szólni, a szolgáltatásaink Model rétegét mostantól kezdve EDM alapokon fogjuk megrajzolni, aztán kész. Sajnos erről ma még szó sincs, az EF Beta 3 jelenleg csak a many-to-many relációval tud többet, mint a LINQ to SQL.

    EF Beta 3 Features

    vs

    EDM Technical Preview June 2006

    De ha a szolgáltatásfejlesztés olyan egyszerű dolog lenne, hogy nem kéne mást tennünk, mint az Entity Framework kontextust és modelleket kieresztjük WCF-en keresztül a nagyvilágba, akkor mi szükség lenne szolgáltatásra, Tisztelt Hölgyeim és Uraim, Kedves Barátaim?? Megadod az Entity Framework-nek a SQL szerver connection stringet, és teljesen ugyan azt a kódot fogod írni, mint a WCF-es megoldás esetében.

    A SOA nem erről szól, az EF egy szerveroldali eszköz. Pont.

    A .NET 4.0-hoz fejlesztett "Oslo Vision" lesz hivatott rendet tenni a zavarosban, bár erről még nagyon keveset tudni.
    Mutasd a teljes hozzászólást!
  • Ezt a sok kínlódást viszont a kész EDM designerrel meglehetne spórolni, ahogy nézem most a videót róla. Csak ránéztem erre a Beta 3-ra. Most világosodtam meg teljesen mindkét részről. Gyakorlatilag ugyanaz, mint amit eddig a Borland ECO tudott, na jó, van LINQ to Entities is. Korábban én abba a hitbe voltam, hogy az ECO ~ Linq To SQL, de szó nincs róla, az ECO teljes értékű ORM eszköz, melyhez ott az OCL nyelv is, ami megfelel az ADO.NET EF Entity SQL-nek. Gyakorlatilag ennyi a különbség, az ECO is kap(ott) WCF támogatást, provider alapú megközelítést, stb. A MS megvalósításában gyakorlatilag viszont mindig az tetszik, hogy nincs telegányolva a kód mindenféle értelmetlen zagyvasággal, ellenben amit az ECO gyárt abból elég kinézni a dolgokat . Másrészt meg működik az ESQL-hez a Linq To Entities, ami viszont nagyon jó. De most megyek, nézem tovább, mert idáig le vagyok nyűgözve. Sajnos ezt nem volt időm tanulmányozni, a régi programok, ill. a WPF meg a Blend elvonja minden figyelmemet, de abba már egyre jobb vagyok és leszek remélhetőleg. Azért nem kis olvasmány ez az utóbbi téma, ha tényleg profin akarsz UI-t tervezni .
    Mutasd a teljes hozzászólást!
  • Utólagos engedelmeddel itt válaszolok a privát üzenetben feltett kérdésre. Nem hinném, hogy Tudástár téma lenne, mert nagyon elméleti jellegű a kérdés, és én is kíváncsi volnék, hogy más hogyan oldaná meg a feladatot. Szóval a kérdések:

    1) Mi a velemenyed, hogy nem keszitek kulon kapcsolotablat a a Ceg <-> Cim es Ember <-> Cim-hez hanem kozos kapcsolotablaban hasznalom - igy, hogy GUID van, mar azonosithato minden sor. Hatranya, hogy vendegkulcs megszoritast nem lehet beallitani a Cet <-> Cim ill. Ember <-> Cim tablak kozott - de nem gond mert ugy is manualisan fogom kezelni a kapcsolt adatokat a WCF miatt. Mit gondolsz?


    Rendszere válogatja, hogy mit kell használni a kapcsolatok adatbázisban történő repreentációjára. A belső reprezentáció úgyis eltűnik a homlokzaton, szóval tényleg úgy oldod meg, ahogy neked, és a későbbi felhasználási igényeknek tetszik. Ebben az a jó, hogy ha menet közben változtatsz valami okból, akkor a kliensek ebből semmit sem fognak észre venni, minden ugyan úgy tud tovább működni. Arra kell figyelni, hogy az az egy kapcsolati tábla egy idő után nagyon lassú lesz, ha már túl sok kapcsolatot kell nyilvántartani. Ellenben sokkal rugalmasabb ez a módszer. Te tudod, hogy mi lesz a nyerő, hogyan fogják a szolgáltatás használni, úgy tervezd meg az adatbázist. A lényeg, hogy a publikált felületen ne kelljen változtatni menet közben.

    2) Elkezdtem felepiteni a Data/Service contract-jaimat manualisan az altalad javasoltak alapjan - ahelyett, hogy a LINQ to SQL generalt osztalyokat publikalnam.
    Kozben jutott eszembe, hogy ok, nem szep dolog kozvetlenul kipublikalni a generalt osztalyokat, ertem akkor mar hivhatna a kliens is a LINQ to SQL-t, de azert meg se vessuk el. Most gyarkorlatilag ugyanazokat az osztalyokat hozom letre manualisan persze mindenfele kiegeszito dologgal - de akkor mar miert ne az eredeti osztalyokat hasznaljam es csak a kiegeszito dolgokat irjam meg? A LINQ to SQL designerben modnjuk leszedhetnem a tabla kapcsolatokat igy nem general ures Company.Adresses-t - hisz ezt kulon kezelem az altalad javasoltak alapjan modnjuk egy kulon GetAdressesByGUID-el.
    Miert dolgozzak foloslegesen? + a LINQ to SQL keszitoiben is csak meg volt a szandek, hogy WCF-en menjenek at az osztalyok kulonben nem tettek volna lehetove, hogy o maga begeneralhassa a DataContract-bejegyzeseket. Nem?


    A rossz hír az, hogy attól, hogy van LINQ to SQL, még dógozni azért kell! ;) Mindenesetre az nem nyerő ötlet, ha leveszed a kapcsolatokat azért, hogy eltűnjenek az asszociációs tulajdonságok! Magaddal szúrsz ki, manuálisan kell írnod a joint. Meg tudod adni, hogy ezek a tulajdonságok internal-ek legyenek, akkor csak a DAL-en belül lehet őket elérni.

    Szóval, ez azért nem nyerő, mert elő fog jönni az az entitás, aminek a publikált formája már nem fog emlékeztetni a LINQ to SQL reprezentációra. Mondjuk azért, mert több táblából fog felépülni, mondjuk. Például cégeket tartasz nyilván, azoknak meg van ágazati kódjuk (TEÁOR, NACE kód). Kell egy entitástípus, ami ezeknek a TEÁOR/NACE kódoknak fogja tárolni a nevét és a leírását, több nyelven. Lesz még egy csomó ilyen kód, a KSH szeret mindennek egy-egy ilyen kódszámot kitalálni. Ennek valami ilyesmi dolgot kell rajzolni a homlokzaton:

    [DataContract] public abstract class CodeDescription { [DataContract] public sealed class Description { [DataMember] public string Name { get; set; } [DataMember] public string Description { get; set; } } [DataMember] public Guid UID { get; set; } [DataMember] public int Code { get; set; } [DataMember] public Dictionary<string, Description> Descriptions { get; set; } } [DataContract] public sealed class TeaorCodeDescription : CodeDescription { } [DataContract] public sealed class NaceCodeDescription : CodeDescription { }

    A Dictionary azonosító string ebben az esetben az ISO kultúra név (pl: hu-HU, en-US). A Guid azonosítás nem feltétlenül szükséges, a típus és a Code tulajdonság is egyértelműen azonosít (nálam ennek a Guid rendszernek architektúrális okai vannak).

    Így néz ki egy-egy kód többnyelvű nevét eltárolni képes üzleti entitás, és én nem látom azt a kallantyút, amivel ehhez hasonlót lehetne rajzolni a LINQ to SQL vagy az SQL Server Management Studio designerében (az Entity Framework más tészta, bár a Beta 3 ehhez még kevés).

    A műveleteket nem írom le. Create, Read, Update (ezen belül: Add, Remove, Update Item), Delete, szóval a szokásos.

    Szóval itt el jön az a pont, amikor lesz olyan contract, amit nem a LINQ to SQL designer rajzolt. Nem lesz egységes a projekt, nem lesznek a dolgok egy helyen, egy idő után tökéletesen karbantarthatatlanná fog válni az egész, főleg, ha nem csak egy adatbáziskontextust és/vagy szolgáltatáshomlokzatot tartalmaz a projekt. Ha csapatban dolgoztok rajta, akkor ez hatványozott problémát fog jelenteni.

    A DAL legyen DAL, a SOAP contract meg legyen SOAP contract, nem jó dolog ezeket keverni.
    Mutasd a teljes hozzászólást!
  • Koszonom a rengeteg hozzaszolast!
    Nagyon hasznos beszelgetes figyeloje lehettem!
    Meg 1x koszonom!
    Most megyek es nyitok egy LINQ to SQL <-> WCF-es kerdessel topic-ot...remelem ott is tudtok segiteni! :)

    A topic neve:
    'LINQ to SQL behind WCF'
    Mutasd a teljes hozzászólást!
  • Egyébként ezt most jelenlegi (proof-of-concept) állapotában úgy kell elképzelni, hogy az egész egy natúr WPF alkalmazás. Van mögötte 2 adatbázis, teljesen azonos sémával, az egyik az MDM-nek, a másik a HUB-nak. Inprocess net.pipe hostolva van az MDM, a HUB, és egy teszt identity provider szervíz, és ezekkel beszélget a WPF mögötti koncepciós logika.

    Muszáj fényezni a WCF-et, mert hiába egy process, a teljes pipeline-on végig fut minden, pont úgy, mintha a szolgáltatások szét lennének szórva a világban. Chain-of-responsibility design pattern, tehát még véletlenül sem fordulhat elő, hogy ebben a teszt üzemmódban keverednek a szolgáltatások és az UI objektumai.

    Annyira jó a WCF, hogy például a szigorú validációs rendszert is nagyon könnyű volt kivitelezni: a validáció WCF OperationBehavior. Ez azt jelenti, hogy mind a kliens proxy, mid a szervíz a műveletek meghívása előtt kötelezően validálni fogja a bemenő üzenetet, és utána a kimenő üzenetet, szóval halálosan idiótabiztos a rendszer, még a saját hülyesége ellen is védve van mindenki. :D Hála Gregorius ötletének, a validációs motorom olyan piszkos gyors és egyszerű lett, hogy abszolút nem kér enne ez a sok, de messze nem felesleges ellenőrzés.

    VS 2008 és .NET 3.5 nélkül messze nem volna ilyen egyszerű a fejlesztés, szóval én maximálisan meg vagyok elégedve az új rendszerrel. \o,
    Mutasd a teljes hozzászólást!
  • viszont adatelérési / master data management megoldásnak rém jónak tűnik...


    Mer ez az volt csak. A forgalmi adatok, műveletek és egyéb elgondolások Workflow alapú rendszer mögött lesznek, tehát a rengeteg állapotfigyelő b'szem-b'szom adatok eltárolásához és irányításához nem kell fekete kakast áldoznom, a WF runtime elintéz mindent hála Istennek. Az egész infrastruktúrájának pedig az ISB-t akarom bevetni, ha kész lesz. Addig elvan fixen bekonfigurált szolgáltatáscímekkel is, jelenleg csak két szervert és néhány klienst kell összehangolni.

    Első körben az MDM a lényeg, mert ez lesz az egyetlen hely, ahol a rendszer hivatkozott adatai származhatnak.
    Mutasd a teljes hozzászólást!
  • ja, kb. erre a konklúzióra jutottam én is, a linq to sql-lel ki lehet váltani a hagyományos dataaccess / mapping réteget, de kb. ezen a ponton ér véget a tudománya (illetve picivel a mapping előtt, hiszen csomó fontos OO elképzelést nem tud rendesen mappelni - pl. több-több kapcsolatot, vagy asszociáció tulajdonságokat).

    amit leírtál, az meg szép, csak két dolog miatt nem egyezik az elképzelésemmel:

    egyrészt én most olyan monolitikus architektúrát akarok építeni, amilyet csak lehet. persze, 100% SOA-ban az összes ilyen kérdésre trivi előáll a válasz, de mi van, ha a projekt nem teszi ezt lehetővé? én most ezt turkálom, hogy mi az a legkisebb designbeli módosítás, ami már lehetővé teszi a törzsadatok vállalati menedzselését

    másik pedig, hogy amit felvázoltál az az adatokról szól. crud műveleteket, és updategramokat írsz le benne. ami alacsony szintű törzsadatok tárolására jó, de nehéz belehegeszteni az üzleti logikát. e fölé az architektúra fölé kellene húzni az üzleti szolgáltatásokat amik az adatkezelést már készen kapnák, de ekkor az üzleti invariánsokat nehéz belehegeszteni (melyik szolgáltatásba teszed?). ráadásul az olyan entitásokat, amiknek nem statikus a viselkedése, rossz benne modellezni.


    viszont adatelérési / master data management megoldásnak rém jónak tűnik...
    Mutasd a teljes hozzászólást!
  • Még annyit felejtettem el, hogy van a rendszernek egy nagyon fontos pontja. Mégpedig az, hogy szükséges biztosítani az egyedi azonosítást már abban az esetben is, ha az adott entitás tulajdonosa nem az MDM, hanem az egyik HUB vagy maga a kliens UI. Ezt nagyon egyszerűen úgy oldottam meg, hogy minden entitás Guid azonosítót kap, és ennek aztán marha mindegy, hogy valójában hol keletkezik. Az Uri azonosítás ebből következően úgy néz ki, hogy az Uri a /20202asd-asd51dsa-54545asd54-4545-re végződik (mondjuk ez egy guid), az eleje pedig azonosítja a típusát és az MDM-et, amibe a végén kerülnie kell. Némelyik entitás meghatároz egy Uri tulajdonságot, ahová fel lehet neki vinni egy egyedi string Uri azonosító-t (és akkor /anyamkinnya -ra fog végződni az Uri), ez pl webes felületeknél hasznos, de ezt a formát csak és kizárólag lekérdezéskritériumokban lehet használni, referenciaazonosításra nem.
    Mutasd a teljes hozzászólást!
  • Hasonló rendszeren dolgozom én is.

    Nekem már az a koncepció sem tetszik, hogy maga az adatbázis az a réteg, ahol biztosítani kell a szinkronizációt. Hibrid adatbázis megoldást használok, úgy van tagolva a rendszer, hogy a különálló feladatoknak lehet saját adatbázisuk, minden entitás egyértelműen azonosítható, nem kér enni.

    A következő a kidolgozás:

    Az MDM szolgáltatás(ok) definiálja(ák) a hozzájuk tartozó entitásmodelleket és relációkat, valamint adnak hozzá egy szabvány stateles SOA menedzsment interfészt.

    Data on the Outside vs. Data on the Inside

    A CRUD természetesen nem hagyományos CRUD:

    - CREATE: Típusos üzenet, egy entitás sablont küld arról, hogy a kliens hogyan szeretné elképzelni az entitást, kiegészítve a létrehozáshoz szükséges asszociációk referencia azonosítóival. Válasz: a keltekezett entitás.

    - READ: Minden asszociáció feloldható, ahol szukséges típusos kritériumok alapján. Ugyan így minden entitáshalmaz (shared collection) elérhető a publikált típusos kritériumok alapján. Egy kritérium minden entitáshalmaz lekéréshez biztos létezik, az azonosító. A kritériumok természetesen csak a menedzsment feladatokhoz vannak meghatározva, kimutatásokhoz, webes-kliens felületekhez külön query szolgáltatások vannak, amik már denormalizált sémákat löknek ki magukból.

    - UPDATE: Semmi olyasmi, hogy elküldök egy entitást a kliensen lévő tulajdonságaival, mert ennek nincs sok értelme, hiszen ez nem atomi üzleti művelet. Minden entitáshoz tartozik UpdateEntityData<T> típusú üzenet, ahol T az az adategység, aminek a változtatását kéri a kliens, pl.: egy cég postai címe, egy alkalmazott neve (rekord: TitleSalutation, FirstName, MiddleName, LastName). Ennek az üzenetnek van egy olyan része, ahol ennek az adatnak el lehet küldeni a kliens (upstream) szerinti verzióját, ezen keresztül történik a konkurenciaellenőrzés. Az MDM szolgáltatásnak nem feladata az, hogy kikösse ennek az előző verziónak az elküldését, egyszerűen akkor végez ellenőrzést, ha az üzenetben ilyen szerepel. Az előző verzió meglétét a policy szabályozza, ez nem az MDM feladata.

    - DELETE: Szokásos üzenet, törli az entitást, ha nincs rá hivatkozás. Ha van, akkor Fault. A delete üzenetnek van egy kill tulajdonsága, ami ha igaz, akkor minden hivatkozott entitással együtt törli az egész cuccot, szintén a policy szabályozza, hogy ki küldhet ilyet, az MDM zokszó nélkül végre fogja hajtani. Az már az upstream feladata, hogy a lekért és esetlegesen befolyásolt entitáshalmazait frissítse, ehhez ott a szabvány READ felület.

    Az üzenetek részletesen naplózva vannak. Ahol szükséges (nem kell minden bisz-basz adathoz ilyen) a visszaállításhoz nélkülözhetetlen DataContractSerializerrel szerializált bináris adatok is el vannak tárolva (pl így van megvalósítva a tombstone). Fontos, hogy nem a nyers adatbázis van naplózva, hanem az MDM contract felület, így ha változik az adatbázis, akkor is minden visszavezethető, ahogy a nagykönyvben meg van írva.

    Ennek az egésznek vagy egy szép felülete, ami egy interface.

    A WPF menedzsment kliens ez alapján határozza meg a taskokat, csak ezt a felületet ismeri, gyakorlatilag teljesértékűen tud működni csak az egyedüli MDM szolgáltatást hívogatva. Ennek felépítése egy külön történet.

    Meg van a felület, innentől kezdve az a feladat, hogy csináljak egy HUB szolgáltatást az updream és az MDM (vagy downstream HUB-ok) közé. Itt van megoldva a szinkroznizáció (és a cache), az up/downstream szinkroznizációs felületet két részre lehet osztani. A felső felét az MDM határozza meg, hiszen ő az egésznek az alja, az alsó felét pedig a HUB, és ő megvalósítja természetesen a felső felét is a dolognak. A szinkronizáció nem birka módon, hanem a logika felépítése alapján történik, mert nyilván nem kell minden adatot átvezetni, lehet szinkronizálni le-fel, meg még amit el lehet képzelni. A két felületet felhasználva aztán lehet szinkronizálni a HUB-HUB, HUM-MDM szolgáltatások adatforgalmát.

    A proof-of-concept verzió lassan el fog készülni, jelenleg épp az UI integráción agyalok, mert a WPF-hez sok mindent újra kell gondolni. Hamar rájöttem, hogy a hagyományos MVC/MVP minta WPF-hez agyhalott megoldás, újet kell kidolgoznom (a .NET 4.0-ig).

    A LINQ to SQL úgy jön a képbe, hogy ez ugye az adatbáziskezelést hivatott támogatni. A LINQ to SQL entitásoknak annyi közük van az MDM entitásmodellekhez és relációkhoz, mint pálmajori Orsós Mari néninek a WPF-hez. A LINQ entitások a táblákra vonatkoznak ugye. A mapping az MDM bizniszlodzsik feladata, valahol a message processor mögött (ezt a logikát öröklik a HUB-ok is, ha SQL 2005-ös adatbázissal dolgoznak). Tehát: jön az üzenet, validáció, message processor - DAL inicializáció. A DAL egy interfész mögött ül, nem akarok mindent újra kezdeni, ha kész lesz az EF. A DAL ojjektum kontextusában ott fog figyelni egy vadi új DataContext pédány, az inicializáció dönti el, hogy read-only-e (ObjectTrackingEnabled = false, így ezerszer gyrosabb, ha nem akarunk írni az adatbázisba). A DAL a homlokzatról a BLL-en keresztül meg fog kapni mindent, ami a művelethez szükséges, validálva, tokkal-vonóval, a DataContract osztályokról nem tud, csak egy interfészt kap a későbbi bővíthetőség miatt (EF ugye). Mivel interfészekkel dolgozik, így a result létrehozásához is kap factory-t a BLL-től, azzal fog dolgozni. Ezek alapján végzi el a LINQ to SQL a megfelelő adatbázisműveleteket és ellenőrzéseket. Ha itt elbukunk valamit, akkor DALException, amiből majd a BLL fogja legyártani a mefelelő üzletileg értelmezett Faultokat.

    Leírni hosszabb, mint megcsináni. :D

    Az LINQ to SQL előnye a szabvány ADO.NET SQL-ezéshez képest, hogy nem kell SQL-t írni minden sz4rhoz, nem kell a data readerekkel szórakozni, a projekció rengeteget segít és mérhetetlen időt lehet megspórolni vele.
    Mutasd a teljes hozzászólást!
  • olvasom a master datás cikkeket, és vicces elképzelésem támadt.

    épp egy mini raktárkészlet-nyilvántartót írok, csak hogy kipróbáljam a linq használhatóságát, ujjgyakorlatként. három entitás van benne: Customer, Product, Order, a szokásos.

    egyelőre totál monolitikus gáz lesz, mintha csak delphiben csináltam volna, de mondjuk azt akarom játszani vele, hogy valami cégszintű integráció révén ezentúl az ügyféladatokat külső rendszerből vegyem majd egyszer.

    a legbénább, totál gyalog megoldás erre az adatbázis-szintű integráció: letiltjuk a customer create-t, és az adatbázist replikáljuk a crm-ből a mi rendszerünkbe, majd ott felveszik az új ügyfelet, átjön, mi meg használjuk.

    de ezt nem akarom, ennél jobbat is tudhatok akár. mondjuk legyen olyan, hogy ha felvesznek nálunk egy ügyfelet, akkor miután adatbázisba mentettük, dobok egy eseményt az új adatokkal. ugyanígy, ha valaki máshol felvett új ügyfelet, akkor azt az eseményt meg nekem kell tudni elkapni. erre már erősen tervezni kell, de még mindig az a megoldás lényege, hogy a saját adatbázisomban szinkron tartom az adatokat. ez se tetszik.

    a totál soa megoldás az lehetne, hogy az ügyfélnyilvántartást kiveszem a programból, önálló szolgáltatást csinálok belőle. ez esetben viszont nem nagyon tudom kihasználni a linq erejét, pl. a Product entitásom (ami a saját adatbázisból jön) Customer asszociációjának (ami viszont más szolgáltatásból jönne) az automatikus feloldására. normál linq to sql-ben tudok ehhez valami lazy read-es feloldót generáltatni, de ilyenkor nem lehet, jól látom?

    (és jól látom azt is, hogy erre majd az Astoria tud megoldást adni? vagy vajon az EF megfelelő providerekkel tudni fogja kezelni?)
    Mutasd a teljes hozzászólást!
  • Eszembe jutott ehhez egy fontos dolog! Írja fel mindenki a talpára, mert én egy teljes napot szívtam vele anno. Tehát, ha inprocess (persze közös AppDomain is) WCF hosting van, mindegy, hogy mi a transport, és ez egy UI alkalmazás (WinForms/WPF), akkor a szervízt megvalósító osztályt (nem a contract felületet!) el kell látni a köv attribútummal:

    [ServiceBehavior(UseSynchronizationContext = false)]

    Mert különben akkora kinyomozhatatlan deadlock lesz belőle, hogy Redmondig elhallatszik.
    Mutasd a teljes hozzászólást!
  • Az Entity Framework egy szolgáltatáscsomag. Leírom, hogy nagyjából hogyan kell elképzelni:

    0. réteg: Vannak a natúr adatok. Adatbázisban, SharePoint-ban, a fájlrendszerben, a búbánatban, mindegy.

    1. réteg: Mapping. Leírja, hogy nyers adatokból hogyan lehet előállítani az EDM modelleket és relációkat és fordítva. A mapping provider ahhoz lesz, amit az MS ad (SQL 2005 + 2008), továbbá ez már alapból nyílt architektúra, lehet hozzá fejleszteni providereket (pl készül az Oracle).

    2. réteg: EDM. A modellek és a relációk definíciója. Ez független minden adatforrástól, koncepcionális réteg. Az SQL 2008 ad arra lehetőséget, hogy a szerveren belül tervezheted meg az EDM-et.

    3. réteg: Egy EDM-hez fejlesztett belső query/command rendszer. Megszűnik az, hogy SQL mondatokkal kommunikálunk, saját binráis felületet kap ez a móka.

    4. a. réteg: eSQL. Tisztára ugyan az a működés, mint a szabvány ADO.NET SQL. SQL kveriket és parancsokat küldünk, azok eredményeit felolvassuk egy readerrel, vagy beletesszük dataset-be, vagy bárhova. Az eSQL-t az EF a belső rendszer nyelvére fordítja. Azért így van ez, mert:

    4. b. réteg: LINQ to Entities. Ez a nyelvi lekérdezésekből állítja elő a belső formátumú lekérdezéseket, és az eredményeket CLR osztályokba pakolja.

    5. réteg: ObjectServices, ami arra való, hogy az EDM modelleket és relációkat CLR osztályokként lássuk.

    Gyökeresen más, mint a LINQ to SQL. Ez egy teljesen új rendszer. Értelem szerűen az EF az SQL Server 2008-cal már a belső lekérdezési formátummal kommunikál, megszünik az SQL nyelv, mint központi koncepció, ez csak egy fícsörré válik, ha valaki nem tud meglenni nélküle.

    Ennyi. Az EF benne lesz a framework frissítésében, erre fog épülni az SQL Server 2008 megvalósítása is, egy szóval az EF a .NET Frameworkben lesz.
    Mutasd a teljes hozzászólást!
  • Ez az EF hol lesz ? A .NET 3.x-nek lesz egy újabb kiegészítése vagy az SQL szerver belső magánügye lesz ? Ha igen akkor hogy fog beszélgetni a LinQ-val és a datasetekkel ?
    Mutasd a teljes hozzászólást!
  • RDMS = RDBMS. Hajnal van még nekem ehhez.
    Mutasd a teljes hozzászólást!
  • Ez az én bibliám, a nagyját ki is nyomtattam magamnak. Alig várom a 3.5-ös írásokat (tervben van olyan, hogy én is írok ide a közeljövőben a 3.5-ös gyakorlati megvalósításokról, bár ehhez még edzenem kell az idén sokat).
    Mutasd a teljes hozzászólást!
  • Még ehhez annyit tennék hozzá, hogy ez volt az Entity Framework EDM része. Az a móka, ahogy az EDM modellekből és relációkból CLR ojjektumok lesznek, EF ObjectServices névre hallgat. Az a rész, amikor LINQ lekérdezésekből EDM-et célzó lekérdezések lesznek nem más, mint a LINQ to Entities. Az a játékos pedig, ami azért felel, hogy az EDM modellekből és relációkból RDMS táblák, lekérdezések és SQL parancsok lesznek, EF Mapping névre hallgat. Ez utóbbi nem csak RDMS hanem más adatforrásokhoz is meg lesz valósítva.
    Mutasd a teljes hozzászólást!
  • látom megijedtél :) viszont a linkelt cikk nagyon király, jó dolgokat ír.
    Mutasd a teljes hozzászólást!
  • viszont ha olyanokat mondasz hogy a szolgáltatásorientáltság refactoring útján előáll, muszáj leszek egy fa karót átverni a szíveden


    Nem azt mondtam. Csak azt, hogy az inprocess WCF szolgáltatások leválasztása Zimbabwe-ben hostolt WS-* szolgáltatásokra nagyrészt csak refactoring és config kérdése. Ettől annak a tervezését már a kezdetektől szolgáltatásorientált architektúra elgondolások alapján kell kitalálni.
    Mutasd a teljes hozzászólást!
abcd