.Net Data Access, wat is nou het beste?

[Lethalis]

Beste tweakers,

Op mijn werk zijn we al een tijdje bezig met het uitzoeken wat nou het handigste is om te communiceren met SQL Server vanuit de gemiddelde VB.Net / C# applicatie. Zelf gebruik ik meestal gewoon een eigen klasse die als wrapper fungeert voor SqlCommand, SqlConnection, etc waarmee ik eenvoudig stored procedures en dergelijke kan uitvoeren en DataTable's terugkrijg.

Hoewel dit erg goed performt, is het niet echt handig als je heel snel dingen wil programmeren, omdat je toch zelf je SQL moet gaan schrijven etc.

Alternatieven die ik heb onderzocht, zijn:
1. Linq2sql
2. Strongly Typed Datasets.

Mijn ervaringen hiermee zijn:

1. Linq2sql

Voordelen:
- SQL wordt voor je gegenereerd
- Optimistic concurrency by default

Nadelen:
- Designer is erg traag, bijna onwerkbaar als meer dan 100 tabellen hebt
- Dynamische vertaalslag naar SQL maakt het ook trager

Ik heb het idee dat Linq2sql niet handig is voor grote projecten.

2. Strongly Typed Datasets

Voordelen:
- Performt beter dan Linq2sql

Nadelen:
- Geen optimistic concurrency by default
- Schijnt verouderd te zijn

Anyway, na al dat onderzoek heb ik nog steeds niet echt een idee van "dit wordt het" en ben ik erg geneigd om gewoon bij mijn oude manier van werken te blijven.

Wat raden jullie aan?

[RedRose]

Misschien een open deur, maar je zou een O/R Mapper kunnen gebruiken? LLBLGen of NHibernate bijvoorbeeld.

offtopic:
Dat ik de dag nog mag meemaken dat whoami mod-af is !

[ Voor 24% gewijzigd door RedRose op 19-02-2009 09:59 ]

[whoami]

Met Linq 2 Sql bedoel je het Entity Framework van MS , of niet ?

Voor een vorig project heb ik gewerkt met 'eigen DAL' classes, en dat is een hoop werk.
Atm gebruik ik NHibernate en voor de moment is het een verademing. Het hangt er natuurlijk vanaf hoe je totale applicatie in elkaar steekt.

[Verwijderd]

whoami schreef op donderdag 19 februari 2009 @ 09:43:
Met Linq 2 Sql bedoel je het Entity Framework van MS , of niet ?

Voor een vorig project heb ik gewerkt met 'eigen DAL' classes, en dat is een hoop werk.
Atm gebruik ik NHibernate en voor de moment is het een verademing. Het hangt er natuurlijk vanaf hoe je totale applicatie in elkaar steekt.

Ik zit met smart te wachten op een productiewaardige Linq 2 nhibernate implementatie. Als ik het goed heb zit daar nu iemand op die een aantal maanden dedicated er aan gaat werken. Gesponsord vanuit een bedrijf die 't wil hebben, maar uiteraard wordt alles vanuit het NH team gestuurd. Ben benieuwd wat dat gaat brengen.

[Lethalis]

RedRose schreef op donderdag 19 februari 2009 @ 09:35:
Misschien een open deur, maar je zou een O/R Mapper kunnen gebruiken? LLBLGen of NHibernate bijvoorbeeld.

Aan de ene kant wel, aan de andere kant wil ik geen extra dependencies in onze projecten krijgen. We zijn juist bezig deze zoveel mogelijk te verwijderen en zoveel mogelijk native te doen met het .Net framework.

Maar ik zal zeker nog naar NHibernate kijken iig.

[Lethalis]

whoami schreef op donderdag 19 februari 2009 @ 09:43:
Met Linq 2 Sql bedoel je het Entity Framework van MS , of niet ?

Voor een vorig project heb ik gewerkt met 'eigen DAL' classes, en dat is een hoop werk.
Atm gebruik ik NHibernate en voor de moment is het een verademing. Het hangt er natuurlijk vanaf hoe je totale applicatie in elkaar steekt.

Linq2sql staat los van het Entity Framework. Het Entity Framework brengt veel overhead met zich mee en is niet echt geschikt voor mijn toepassingen. Het brengt een extra scheiding aan tussen de data laag en de entiteiten.

Ik gebruik ook eigen DAL classes, maar het extra werk is dus precies het probleem.

[RedRose]

De logica dat extra dependencies extra werk op zouden leveren ontgaat me even. Of je nou een OR mapper gebruikt of je eigen DAL, dat blijft toch een dependency. Of ik begrijp niet wat je met 'dependency' bedoelt.

Waar zie je een extra scheiding tussen de data laag en de entiteiten? En wat zou daar mis mee zijn? Alles in 1 tier willen stoppen is op zeker slecht design. En meer dan 100 tabellen misschien trouwens ook wel.

Het is in ieder geval niet zo dat het weghalen van lagen (DAL -> Entities en / of BL -> enz) minder werk oplevert, of dat het daardoor sneller / beter werkt. Dat hangt voor een groot deel af van je ontwerp. En het gebruik van bestaande tools for the job besparen je dan een hoop werk.

[ Voor 5% gewijzigd door RedRose op 19-02-2009 10:42 ]

[rewind.]

Ik gebruik castle activerecord is een laagje bovenop nhibernate en moet zeggen dat het tot nu toe erg makkelijk werkt!

[whoami]

Lethalis schreef op donderdag 19 februari 2009 @ 10:15:
[...]

Aan de ene kant wel, aan de andere kant wil ik geen extra dependencies in onze projecten krijgen. We zijn juist bezig deze zoveel mogelijk te verwijderen en zoveel mogelijk native te doen met het .Net framework.

En wat is het nut daarvan ?
Investeer je dan liever extra ontwikkeltijd om alles zelf te doen, om maar zo weinig mogelijk dependencies te hebben, ipv iets te gebruiken dat z'n diensten al 'in the field' bewezen heeft (en nota bene ook nog gratis is) ?

Klinkt een beetje als het 'not invented here syndrome'.

[EfBe]

Verwijderd schreef op donderdag 19 februari 2009 @ 10:12:
[...]
Ik zit met smart te wachten op een productiewaardige Linq 2 nhibernate implementatie. Als ik het goed heb zit daar nu iemand op die een aantal maanden dedicated er aan gaat werken. Gesponsord vanuit een bedrijf die 't wil hebben, maar uiteraard wordt alles vanuit het NH team gestuurd. Ben benieuwd wat dat gaat brengen.

Sinds wanneer? Mij heeft het 9 maanden full time gekost en het is geen kattedrek. Ik weet niet of het bedrijf in kwestie 9 maanden full development wil betalen voor een linq provider die toevoegt dat je kunt queryen met linq maar an sig niet meer toevoegt nhibernate's eigen query api al biedt. Er zijn verschillende pogingen gedaan om linq to nhibernate te maken, maar ze strandden allemaal voortijdig.

We zitten er wel over te denken om onze linq provider (die alles implementeert itt de meeste concurrenten) te porten naar nhibernate voor v3, maar ook dat gaat wel de nodige tijd kosten.

[Lethalis]

RedRose schreef op donderdag 19 februari 2009 @ 10:40:
1) De logica dat extra dependencies extra werk op zouden leveren ontgaat me even. Of je nou een OR mapper gebruikt of je eigen DAL, dat blijft toch een dependency. Of ik begrijp niet wat je met 'dependency' bedoelt.

2) Waar zie je een extra scheiding tussen de data laag en de entiteiten? En wat zou daar mis mee zijn? Alles in 1 tier willen stoppen is op zeker slecht design. En meer dan 100 tabellen misschien trouwens ook wel.

1) Er is meer dan alleen het programmeerwerk, we maken immers ook client applicaties die bij honderden klanten staan. Het is wat dat betreft handig om het deployment daarvan zo eenvoudig mogelijk te houden.

Want het nadeel met 3rd party assemblies is vaak de wildgroei aan versies die bij klanten staan. Het moet dus makkelijk met xcopy deployment gewoon werken en klaar.

2) Linq 2 entities brengt een extra scheiding aan, die Linq 2 sql niet heeft.

Het nadeel daarvan is "gemak" en "performance".

Ik moet wel zeggen dat het een moeilijke kwestie blijft, omdat verschillende applicaties verschillende eisen hebben en dat in direct conflict staat met de wens om alles op eenzelfde manier te doen die het hele team begrijpt.

Zelf ben ik hier de lokale SQL Server expert, doe graag dingen met Stored Procedures en weet goed mijn weg te vinden met het maken van de juiste indexes om zoveel mogelijk performance te halen uit bestaande hardware en software. Dat kan heel belangrijk zijn bij server / web applicaties, maar misschien ondergeschikt bij Windows client programmatuur waar de onderhoudbaarheid van het geheel zwaarder weegt dan performance.

[Lethalis]

whoami schreef op donderdag 19 februari 2009 @ 10:55:
[...]
En wat is het nut daarvan ?
Investeer je dan liever extra ontwikkeltijd om alles zelf te doen, om maar zo weinig mogelijk dependencies te hebben, ipv iets te gebruiken dat z'n diensten al 'in the field' bewezen heeft (en nota bene ook nog gratis is) ?

Klinkt een beetje als het 'not invented here syndrome'.

Ik heb al aangegeven onderzoek te doen naar nhibernate, dus ik begrijp je reactie niet helemaal.

Maar ik zal naar verschillende aspecten moeten kijken, waaronder performance, ease of deployment, het gemak waarmee je ermee kan ontwikkelen (omdat ik het aan anderen zou moeten uitleggen), etc, etc, etc.

[EfBe]

Lethalis schreef op donderdag 19 februari 2009 @ 11:48:
[...]
1) Er is meer dan alleen het programmeerwerk, we maken immers ook client applicaties die bij honderden klanten staan. Het is wat dat betreft handig om het deployment daarvan zo eenvoudig mogelijk te houden.

Want het nadeel met 3rd party assemblies is vaak de wildgroei aan versies die bij klanten staan. Het moet dus makkelijk met xcopy deployment gewoon werken en klaar.

Ik ken geen .net assemblies die niet via xcopy deployment geinstalleerd kunnen worden, tenzij alles in de GAC gepleurd wordt op locatie, wat niet zou moeten.

En de aversie tegen 3rd party spul is ook van toepassing op grid controls e.d.? Of niet?

2) Linq 2 entities brengt een extra scheiding aan, die Linq 2 sql niet heeft.

Welke scheiding? Linq to sql kan nog middels POCO gebruikt worden, het EF niet.

Het nadeel daarvan is "gemak" en "performance".

Ik moet wel zeggen dat het een moeilijke kwestie blijft, omdat verschillende applicaties verschillende eisen hebben en dat in direct conflict staat met de wens om alles op eenzelfde manier te doen die het hele team begrijpt.

Ik heb er een tijdje geleden een blogpost over geschreven:
http://weblogs.asp.net/fb...s-still-your-problem.aspx

Het punt is: je moet niet in de klant zn tijd infrastructure code gaan zitten schrijven, daarvoor word je niet betaald. Ga je dus investeren in het maken van een framework, dan is dat echt overboord gegooid geld en tijd, er zijn er nl. al voldoende. Verschillende applicaties vragen nu eenmaal om verschillende dingen, maar ik snap niet echt waarom dat een probleem is mbt data-access, want dat is echt universeel. En ja, er is geen framework die precies doet wat jij voor de klant moet maken, maar anders zat je ook zonder werk

Zelf ben ik hier de lokale SQL Server expert, doe graag dingen met Stored Procedures en weet goed mijn weg te vinden met het maken van de juiste indexes om zoveel mogelijk performance te halen uit bestaande hardware en software. Dat kan heel belangrijk zijn bij server / web applicaties, maar misschien ondergeschikt bij Windows client programmatuur waar de onderhoudbaarheid van het geheel zwaarder weegt dan performance.

Sinds wanneer is een o/r mapper trager dan stored procs? Want dan weet ik nog wel wat situaties voor je . Serieus: het punt is dat de klant jou betaalt om een applicatie te bouwen. Als jij in die tijd niet bezig bent met het probleem van de klant maar met infrastructure code en DAARNA pas met de applicatie van de klant bezig kan, dan ben je verkeerd bezig: de klant betaalt dan nl. voor dingen waar ze helemaal niet voor hoeft te betalen. Ik betaal een loodgieter ook niet 15 mille zodat hij een busje kan kopen om zn reut te vervoeren naar mijn huis.

[Lethalis]

EfBe schreef op donderdag 19 februari 2009 @ 12:00:
[...]
Serieus: het punt is dat de klant jou betaalt om een applicatie te bouwen. Als jij in die tijd niet bezig bent met het probleem van de klant maar met infrastructure code en DAARNA pas met de applicatie van de klant bezig kan, dan ben je verkeerd bezig: de klant betaalt dan nl. voor dingen waar ze helemaal niet voor hoeft te betalen. Ik betaal een loodgieter ook niet 15 mille zodat hij een busje kan kopen om zn reut te vervoeren naar mijn huis.

Ik begrijp niet waar je het vandaan haalt om ineens zo'n opmerking te plaatsen.

Je hebt helemaal geen idee van de hoeveelheid tijd die ik hieraan besteed ten opzichte van werkelijke ontwikkeltijd, en bovendien wiens tijd dat is.

[beany]

Lethalis schreef op donderdag 19 februari 2009 @ 13:36:
[...]

Ik begrijp niet waar je het vandaan haalt om ineens zo'n opmerking te plaatsen.

Je hebt helemaal geen idee van de hoeveelheid tijd die ik hieraan besteed ten opzichte van werkelijke ontwikkeltijd, en bovendien wiens tijd dat is.

Al weet EfBe wel een klein beetje wat er aan tijd gaat zitten in het ontwikkelen van een framework.......

[Lethalis]

beany schreef op donderdag 19 februari 2009 @ 13:38:
[...]
Al weet EfBe wel een klein beetje wat er aan tijd gaat zitten in het ontwikkelen van een framework.......

Wie zegt dat ik dat ga doen voor dit specifieke probleem?

Ik probeer uit te zoeken wat het beste is voor onze situatie op kantoor, ik heb nog lang niet besloten wat ik ga doen en of ik er ueberhaupt iets aan ga doen.

Op dit moment programmeert zo'n beetje elke programmeur bij mij op kantoor z'n eigen DAL, niemand weet wat de ander precies doet, etc. Plus dat er heel veel werk dubbel gedaan wordt, terwijl achteraf blijkt dat we veel al eens eerder hebben gedaan (bijvoorbeeld een postcode check, ik noem maar wat).

Dat kan je tegen gaan door een gemene deler te vinden, standaards te gebruiken, een library te onderhouden die iedereen gebruikt. Data access maakt daarvan maar een heel klein gedeelte uit, maar je moet ergens beginnen.

Uiteindelijk gaat dat ervoor zorgen dat we juist tijd gaan besparen, omdat code er leesbaarder van wordt, klassen hergebruikt gaan worden, etc.

[EfBe]

Lethalis schreef op donderdag 19 februari 2009 @ 13:36:
[...]
Ik begrijp niet waar je het vandaan haalt om ineens zo'n opmerking te plaatsen.

je wilt beweren dat je niet zelf DAL code aan het schrijven bent? Ik bedoelde precies dit:

Op dit moment programmeert zo'n beetje elke programmeur bij mij op kantoor z'n eigen DAL, niemand weet wat de ander precies doet, etc. Plus dat er heel veel werk dubbel gedaan wordt, terwijl achteraf blijkt dat we veel al eens eerder hebben gedaan (bijvoorbeeld een postcode check, ik noem maar wat).

En iedere 'DAL' die daar gemaakt wordt is in de klant zn tijd gemaakt.

Je hebt helemaal geen idee van de hoeveelheid tijd die ik hieraan besteed ten opzichte van werkelijke ontwikkeltijd, en bovendien wiens tijd dat is.

Jawel hoor, want ik ben een van het select groepje O/R mapper developers in de wereld die zo'n framework volledig hebben ontworpen en gebouwd. Nu hoeft een custom DAL niet al die features te hebben, maar ik weet wel welke problemen je moet oplossen en hoeveel tijd het kost om alles goed te krijgen. Voor een beetje applicatie ben je echt wel veel tijd kwijt aan het schrijven van data-access code, zeker als je alles zelf gaat doen (dus geen framework gebruikt).

Het punt is dat je in gaat zien dat, maakt niet uit welk framework (maar dus wel 1 die wat solide is), je EEN framework gaat gebruiken. Zodoende los je op:
1) bouwtijd voor de DAL, die is er niet, want het framework ligt er al, je kunt direct beginnen met bouwen van je applicatie. LLBLGen Pro heeft qua ontwikkeltijd ong 7 manjaar gekost, met meer dan 600.000 regels code. Je zult niet alles nodig hebben van zo'n framework, maar wel dat je toch wel tegen een 4-5 maanden aan werk aan zit te kijken van een erg compacte custom DAL die puur query uitvoert en results in objects dumpt en wat consistency checks doet, change tracking etc.
2) consistentie: iedereen gebruikt hetzelfde framework, dus je hoeft niet bang te zijn dat er iets dubbel gemaakt wordt, immers alle code die je schrijft is code voor de klant, niet framework code.
3) maintenance: je DAL code hoef je niet te onderhouden, dat wordt voor je gedaan.
4) missing features: je DAL code heeft alle features die je mogelijkerwijs tegen gaat komen, zoals graph saving, pk/fk syncing, graph fetching, etc. etc. dus je hoeft niet bang te zijn dat de development voor de klant tegenslag ondervindt omdat je eerst iets in de DAL moet bouwen om het te bereiken.

Software bouwen voor een klant is kijken wat je kunt outsourcen naar 3rd party libraries, zodat je niet dat zelf hoeft te doen. Dat bespaart tijd en dus geld. Want geloof me, jij gaat echt geen winst maken op het schrijven van DAL code. Net zo min dat je niet zelf je Grid controls gaat zitten maken, maar die ook van een 3rd party koopt, de redenatie is hetzelfde. Tuurlijk is het maken van framework code leuk, maar face it, daarvoor worden applicatieprogrammeurs niet betaalt, hoe wrang dat ook mag klinken.

Om terug te komen op je vraag, wat is de beste? Het hangt af van hoe je wilt werken. Bijna alle data-access frameworks genereren zelf SQL. Wil je stored procedures blijven gebruiken voor CRUD, dan lever je veel functionaliteit in, want je hebt dan niet de flexibiliteit om bv graphs te fetchen (customers with filter + hun orders + order details in 3 queries). Wil je per-se stored procedures blijven voor CRUD, gebruik dan iBatis van Apache, simpel en doet wat je wilt. Het levert wel meer werk op: je moet stored procs blijven schrijven. Voor 10 tables gaat dat nog, voor 100 wordt dat al veel werk.

Wil je per-se POCO classes gebruiken, dus je eigen domain classes gebruiken en die mappen op tables, dan kun je nhibernate gebruiken, of bv EUSS. Wil je gemak en heb je bv al tables dan kun je ons framework LLBLGen Pro gebruiken, die hou je tegen je database aan, en je bouwt dan het entity model weer op.

MS' varianten zitten hier een beetje tussenin. Entity Framework heeft veel limitaties, het is echt een v1.0 product waarbij ik me soms afvraag of het niet te vroeg is gereleased. Wil je per-se MS' frameworks gebruiken, dan zou ik toch Linq to sql kiezen, al heeft die ook weer wat nadelen: geen M:N relations, geen inheritance over meerdere tables (target per entity) en hierarchical fetches zijn erg traag.

[Lethalis]

EfBe schreef op donderdag 19 februari 2009 @ 14:38:
[...]
Om terug te komen op je vraag, wat is de beste?

Dat is in feite het enige dat ik wil weten

Wil je stored procedures blijven gebruiken voor CRUD

Nee, maar ik wil wel de mogelijkheid hebben om Stored Procedures te gebruiken (voor bepaalde functionaliteit waarbij het zonde zou zijn van de roundtrips als ik dat niet zou doen).

Dus zoals het in Linq2sql werkt (stored procedure naar designer slepen, is in principe prima, ware het niet dat het framework an sich aanvoelt als een pre-beta).

Je laatste post is gelukkig eindelijk wat ik zoek: wat uitleg over de voor- en nadelen van de diverse frameworks die er al zijn

[EfBe]

Lethalis schreef op donderdag 19 februari 2009 @ 14:55:
[...]
Nee, maar ik wil wel de mogelijkheid hebben om Stored Procedures te gebruiken (voor bepaalde functionaliteit waarbij het zonde zou zijn van de roundtrips als ik dat niet zou doen).

Veel o/r mappers (NHibernate, LLBLGen Pro, Entity framework, linq to sql etc. ) laten het toe om procs aan te roepen, bv voor lang lopende batch processen. NHibernate via static SQL in config files, llblgen pro door een proc als call in het project te hangen (paar keer klikken) en de call code wordt gegenereerd.

An sig is het aanroepen van een paar zware procs de hele wereld niet, daar kun je best wat custom code voor schrijven, het bulkwerk voor applicaties is toch CRUD.

[Verwijderd]

Waarom zou jeje eigen DAL schrijven? Daar hebben al heel veel mensen over nagedacht. Ik zou hun frameworks etc, gebruiken.

Als jeje eigen DAL schrijft ben je alleen maar bezig met "Plumming" code om je code te laten samenwerken met de DB. Je gaat toch ook niet je eigen OS schrijven of je eigen GUI classes?

Lees http://codebetter.com/blo...of-programming-ebook.aspx maar eens.

[Verwijderd]

offtopic:
Plumbing, zoals een plumber doet

Ik ben ook begonnen met het uitdenken en ontwerpen van een dergelijk stukje software, als hobbyprojectje.
Waarom?
a) omdat ik het interessant vind;
b) omdat het kan
Het is ontzettend interessante materie waar ik een hoop creativiteit in kwijt kan, ik vind raakvlakken met concurrency, data-access en parsing/grammars, allemaal dingen die ik erg interessant vind en het lijkt wel of bij alles wat ik bedenk ik weer tig nieuwe dingen kan bedenken.

Het blijkt een enorme katalysator te zijn die het doen van onderzoek naar van alles en nog wat op software ontwikkelings gebied óntzettend stimuleert bij me. Dat is toch veel belangrijker dan het wel of niet al bestaan van dergelijke software

Waarom zou jeje eigen DAL schrijven?

Zie bovenstaand, nu snap ik wel dat je dat niet in je baas z'n tijd moet gaan zitten doen. Maar om het helemaal af te doen als onzin is wel erg kort door de bocht.

[ Voor 12% gewijzigd door Verwijderd op 19-02-2009 16:15 ]

[Lethalis]

Verwijderd schreef op donderdag 19 februari 2009 @ 15:29:
Waarom zou jeje eigen DAL schrijven? Daar hebben al heel veel mensen over nagedacht. Ik zou hun frameworks etc, gebruiken.

Als jeje eigen DAL schrijft ben je alleen maar bezig met "Plumming" code om je code te laten samenwerken met de DB. Je gaat toch ook niet je eigen OS schrijven of je eigen GUI classes?

Lees http://codebetter.com/blo...of-programming-ebook.aspx maar eens.

Nogmaals, ik wil geen DAL gaan schrijven, ik wil de voor- en nadelen van de verschillende frameworks weten en de ervaringen die mensen ermee hebben

PS:
Alsnog bedankt voor de link, staan wel een hoop interessante dingen in.

[Verwijderd]

Lethalis schreef op donderdag 19 februari 2009 @ 17:13:
[...]

Nogmaals, ik wil geen DAL gaan schrijven, ik wil de voor- en nadelen van de verschillende frameworks weten en de ervaringen die mensen ermee hebben

PS:
Alsnog bedankt voor de link, staan wel een hoop interessante dingen in.

Voordelen eigen DAL:
- lijkt veel leuker
- lekker aanklooien (no offense)
Nadelen:
- het is onwaarschijnlijk dat je de functionaliteit die op dit moment geboden wordt door llblgen of NHibernate snel kunt evenaren. Het punt dat dit dan verkwiste knaken zijn is gewoon valide. Niet over zeuren, gewoon niet doen.

Veel belangrijker in het oogpunt van je oorspronkelijke vraag mbt de voor en nadelen van de frameworks is dit: hoeveel tijd kost het je om je team te trainen en welke mogelijkheden biedt het framework?

Llblgen, niet mee gewerkt, maar script een DAL obv je db. Lekker snel en makeklijk om via de traditionele weg applicaties van CRUD te voorzien. Voordeel is dat data access geregeld is, logica stop je in je BL => beter testbaar, beter onhoudbaar en x-keer beter te refactoren. Je blijft natuurlijk wel zitten met mapping tegen je db.

NHibernate: design prinicpe dat je gebruikt is fundamenteel anders. Eerst je domein klasse's vormgeven, persistentie denk je niet over na (je maakt wat mapping files en that's it). Op dit moment wordt er nogal wat tijd en energie gestoken in Fluent NHibernate dat ervoor zorgt dat je persistentie laag op een redelijk eenvoudige manier mee evolueert met je domein model. Er is een vrij goeie screencast serie beschikbaar via
www.summerofnhibernate.com. Ben zelf grote voorstander van NHibernate, is op dit moment ook zowat de standaard in de hippe blogs (codebetter, devlicious en lostechies).
Werk zelf voor een dochter van Microsoft, maar wij zijn niet te beroerd om verder te kijken dan onze neus lang is.

Bepaal eerst welke kant je op wilt gaan in je applicatie development. Wat voor applicaties bouw je? Is er een ttendens om richting DDD te gaan? If so, dan zou ik zeker NHibernate de voorkeur geven. Maar uiteindelijk is het vooral belangrijk in te zien dat de mainstream persistentie variant ook maar tijdelijk is. Zorg er dus voor dat ie inwisselbaar is op het moment dat er iets beters voorhanden is.

[Eriksk]

Van het weekend even het boek PRO: Linq, ORM in C#2008 doorgelezen. De focus in dit boek ligt op Linq2SQL en het EF-framework, maar toch worden nog een aantal andere frameworks behandeld (NHibernate en LLBLGen PRO). Wellicht handig om dit mee te nemen in je overweging.

Zelf zou ik niet kiezen voor Linq2SQL. Deze is te beperkt en is meer 'zoethoudertje' totdat EF* uitkwam en vooral geschikt voor RAD.

*EF: Dat zou mijn eerste keus zijn, omdat we vooral met MS-tooling werken. Helaas verliep de ontwikkeling niet zoals gepland, waardoor eerst Linq2SQL te lang de enige optie was en v2 de versie wordt waarop iedereen wacht.

NHibernate en LLBLGen PRO heb ik (nog) niet bekeken, maar die worden erg vaak genoemd in het rijtje goede OR-Mappers.

Zelf ben ik ook een aanhanger van het gebruik van sprocs, maar ik kom hier langzaam maar zeker toch op terug in dit verhaal. Je moet natuurlijk wel in de gaten houden wat voor een queries er gegenereerd worden t.b.v performance. Door het maken van query executing plans, statistieken en indexen zullen goedopgestelde queries nauwelijks onderdoen voor sprocs.

[whoami]

[b][message=31540077,noline]

*EF: Dat zou mijn eerste keus zijn, omdat we vooral met MS-tooling werken.

Dit vind ik een ietwat rare redenering ...
Ik denk dat je een tool / framework moet kiezen op basis van z'n functionaliteit en niet op basis van welke leverancier het komt.
Aangezien ik ook lees dat je de 2 'grote' spelers nog niet bekeken hebt, is het alsof je oogkleppen op hebt.

[Eriksk]

Nah, ik heb het niet handig opgeschreven... maar op dit moment is het mijn eerste keus (mede door het ontbreken van kennis over de overige twee spelers).

whoami schreef op maandag 23 februari 2009 @ 09:43:
[...]
Ik denk dat je een tool / framework moet kiezen op basis van z'n functionaliteit en niet op basis van welke leverancier het komt.

Zoals jij het typt lijkt het dat wat ik geschreven heb de enige beweegredenen zijn om voor EF te kiezen. Dat is dus absoluut niet zo. Anders had ik wel direct voor Linq2SQL gekozen...

Zaligmakend vind ik het niet, maar het is wel een pluspunt als je tooling van dezelfde leverancier hebt.

[Lethalis]

Ik werk voornamelijk aan ASP.Net websites / server apps.

Anyway, ik ben in de tijd die ik over heb bezig met mijn eerste nhibernate test projectje. Moet alles nog opzetten, maar voorlopig zal de keuze daar op vallen denk ik.

Zijn er eigenlijk ook nog handige tooltjes om poco classes te genereren op basis van je data? Ik weet inmiddels dat dit niet echt strookt met domain driven design, maar het zou wel een hoop tijd besparen in veel gevallen. Eerst de classes genereren, en ze daarna zelf aanpassen en uitbreiden met functionaliteit.

PS:
http://forum.hibernate.org/viewtopic.php?t=985289

Ik had versie 2.0 gedownload en het werkte steeds maar niet

Nu kan ik eindelijk ermee experimenteren

[ Voor 13% gewijzigd door Lethalis op 23-02-2009 14:04 ]

[EfBe]

Eriksk schreef op maandag 23 februari 2009 @ 09:34:
Van het weekend even het boek PRO: Linq, ORM in C#2008 doorgelezen. De focus in dit boek ligt op Linq2SQL en het EF-framework, maar toch worden nog een aantal andere frameworks behandeld (NHibernate en LLBLGen PRO). Wellicht handig om dit mee te nemen in je overweging.

Zelf zou ik niet kiezen voor Linq2SQL. Deze is te beperkt en is meer 'zoethoudertje' totdat EF* uitkwam en vooral geschikt voor RAD.

Nou, dat wil Management in Redmond je graag doen geloven, maar feit is dat Linq to sql gemaakt is door het C# team wat Linq maakte en het in feite gebruikt heeft als default implementatie voor IQueryable en er gewoon veel eerder mee klaar was. Dat het EF er later bij kwam is eigenlijk meer het gevolg van het feit dat binnen MS verschillende teams gewoon strijden voor geld om iets te maken (er zijn bv ook verschillende database engine teams). Linq to Sql is nu ondergebracht bij het EF team, en feitelijk opgeschreven, omdat het EF team niet geinteresseerd is om Linq to sql naar een hoger plan te tillen, er is immers het EF. Maar kijk niet raar op als Linq to sql over een paar jaar weer uit de kast wordt gehaald nadat men er van overtuigd geraakt is dat de ramp genaamd Entity framework toch niet bracht wat men verwachtte.

*EF: Dat zou mijn eerste keus zijn, omdat we vooral met MS-tooling werken. Helaas verliep de ontwikkeling niet zoals gepland, waardoor eerst Linq2SQL te lang de enige optie was en v2 de versie wordt waarop iedereen wacht.

V2 van EF wordt niet veel beter. Er is nog steeds geen oplossing voor grote projects (nog steeds 1canvas) en geen oplossing voor change management in distributed scenario's. Ik weet niet wat die grote groep developers aan het doen zijn de hele dag, maar als ze ook maar 10 minuten per dag hadden ingezet voor het EF dan waren ze al klaar geweest met al deze problemen.

[ Voor 10% gewijzigd door EfBe op 23-02-2009 14:55 ]

[beany]

EfBe schreef op maandag 23 februari 2009 @ 14:53:
[...]
nadat men er van overtuigd geraakt is dat de ramp genaamd Entity framework toch niet bracht wat men verwachtte.

Het lijkt wel, gezien de geschiedenis van MS projecten op dit gebied, alsof ze niet willen dat er een goed werkend product komt... Want ik weet geen enkele oplossing van MS die ooit goed was, wat dit betreft dan.

[Verwijderd]

beany schreef op maandag 23 februari 2009 @ 19:20:
[...]

Het lijkt wel, gezien de geschiedenis van MS projecten op dit gebied, alsof ze niet willen dat er een goed werkend product komt... Want ik weet geen enkele oplossing van MS die ooit goed was, wat dit betreft dan.

Toegegeven, MS eerste versies zijn vaak crappy, maar hoe kijk je nu tegen VS2008, Sqlserver2008, server2008 of Biztalk2006 aan (product)? Of tegen Unity of Linq?

[beany]

Verwijderd schreef op dinsdag 24 februari 2009 @ 17:52:
[...]


Toegegeven, MS eerste versies zijn vaak crappy, maar hoe kijk je nu tegen VS2008, Sqlserver2008, server2008 of Biztalk2006 aan (product)? Of tegen Unity of Linq?

Nou had ik het specifiek over het benaderen van data. Het was absoluut geen flame, of iig niet zo bedoeld

Visual Studio 2008 kan ik heel simpel over zijn: dat is voor mij gewoon de allerbeste IDE ter wereld.
SqlServer 2008: verdomd goeie database, maar ik moet toegeven dat weinig ervaring heb met andere DB's
BizTalk: nooit mee gewerkt
Unity: kende ik niet, ff wat over lezen
Linq: leuk, krachtig, maar het is het net niet

Maar goed, ik had het niet over MS producten in het algemeen. MS maakt best goede producten, maar ze maken hier en daar ook slechte producten.

Aan de andere kant, als we het over data access hebben, we moeten we iets te wensen houden he

[Verwijderd]

beany schreef op dinsdag 24 februari 2009 @ 19:29:
[...]

Nou had ik het specifiek over het benaderen van data. Het was absoluut geen flame, of iig niet zo bedoeld

Aan de andere kant, als we het over data access hebben, we moeten we iets te wensen houden he

Mijn excuses, reageerde ietwat geprikkeld idd

Klopt, maar richt je dan op NHibernate. Icm Fluent NHibernate en Linq2NHibernate is het een hele krachtige tool. MS is gewoon druk bezig ook met een orm mapper op de proppen te komen. Concept is tot nu toe nog altijd geweest de kunst af te kijken, in te stappen, falen. Tweede iteratie is vaak stuk beter waarna het gaat vliegen bij iteratie 3 of 4.

Belangrijk aspect voor MS is altijd geweest data access zo toegankelijk mogelijk te krijgen. Het geklooi met datasets was bepaald niet elegant, maar wel erg toegankelijk. Linq to sql was dat ook maar is afgeschoten.

off topic: als je met Unity aan de slag gaat moet je ook eens kijken naar Structuremap. Voor productie gebruik ik Unity, maar in test de automocker van structuremap; erg mooi allemaal.

[Verwijderd]

Was SubSonic al genoemd?

http://subsonicproject.com/

Toch jammer dat ik nog studeer, en niet fatsoenlijk mijn tanden in deze mooie dingen kan zetten

[whoami]

Verwijderd schreef op zaterdag 28 februari 2009 @ 03:07:

Toch jammer dat ik nog studeer, en niet fatsoenlijk mijn tanden in deze mooie dingen kan zetten

Vind ik een raar statement ....
Nu je nog studeert , heb je alle mogelijkheden & tijd om je eens in bepaalde van die frameworks te verdiepen.

[Verwijderd]

Misschien ook een op deze site kijken? > http://imar.spaanjaars.com

Staan aardige artikelen over N-Layered Web Applications with ASP.NET

De auteur is schrijver bij Wrox en Nederlander en niet te beroerd om je van tips te voorzien.

[Verwijderd]

whoami schreef op zaterdag 28 februari 2009 @ 08:29:
[...]

Vind ik een raar statement ....
Nu je nog studeert , heb je alle mogelijkheden & tijd om je eens in bepaalde van die frameworks te verdiepen.

True, maar niet in een "echt" project om te zien hoe het uitpakt enzovoort. En ik kan het niet mentaal opbrengen om code te schrijven waar niemand wat aan heeft.

[MrBucket]

Deze opmerking:

Lethalis schreef op maandag 23 februari 2009 @ 13:10:
Zijn er eigenlijk ook nog handige tooltjes om poco classes te genereren op basis van je data? Ik weet inmiddels dat dit niet echt strookt met domain driven design, maar het zou wel een hoop tijd besparen in veel gevallen. Eerst de classes genereren, en ze daarna zelf aanpassen en uitbreiden met functionaliteit.

...gecombineerd met je eerdere opmerking dat je zelf een beetje een database-man bent, zou je kunnen doen overwegen om een template processor a la CodeSmith of MyGeneration in te zetten. Deze kunnen op basis van je databaseschema stukken tekst (C#, VB.NET en/of SQL) genereren. Dit kun je gebruiken om je entity classes, entity managers en CRUD stored procedures te genereren op basis van je tabeldefinities.

Voordelen:
* Je kunt de features van je data-access laag zelf definieren en tot in de puntjes bepalen en tweaken. Wil je optimistic concurrency control? Houden je entity classes bij of ze dirty zijn of niet? Wil je directe foreign key waardes of collecties van gerelateerde entiteiten? Moeten je collecties van gerelateerde entiteiten IBindingList implementeren? Wil je in elke SP een autorisatie-controle, of wil je die in je entity manager, of... Etc.
* Je krijgt compile time checking van je gebruikte attributen (= kolommen in SQL) en relaties: Als je database-schema verandert en je genereert je data-access laag opnieuw zal je code niet compilen wanneer je een attribuut of relatie benadert die veranderd of verdwenen is.
* Je bent vrij om te kiezen om alles via stored procedures te regelen, alles via SqlCommands of een variant ertussen in. Je kunt je database-component zo groot of klein maken als je zelf wilt.
* Je kunt je gegenereerde code altijd uitbreiden (mbv partial classes of inheritance) om zo getweakte functionaliteit toe te voegen aan de standaard gegenereerde functionaliteit.

Nadelen:
* De prijs voor volledige flexibiliteit: Je zult de templates in eerste instantie wel zelf moeten schrijven - het is zeker geen kant en klare oplossing. Als je eenmaal een goede set templates hebt die overeenkomen met de gemene deler van functionaliteit die je in de meeste projecten nodig hebt, dan scheelt het je in volgende projecten het werk van opnieuw een data-access laag schrijven. Maar initieel kost het je wel werk.
* Simpele select-SP's genereren lukt nog wel (select by id, select by foreign key, select by alternate key, select all), maar met name complexe(re) selectiecriteria en joins over meer dan 2 tabellen gaan lastig worden om uit te genereren op basis van alleen je databaseschema. Houd er rekening mee dat je dit soort situaties handmatig zult moeten blijven doen.
* Indien je lazy loading of (complexe) change-tracking wilt, zul je dit dus ook helemaal zelf uit moeten werken, daar waar andere frameworks dit voor je doen. Dit is geen sinecure (ten opzichte van een onhandige out-of-the-box implementatie in een bestaand framework ben je misschien beter af om het uberhaupt niet tot je beschikking te hebben, dan heb je er ook geen last van), maar als je het wel wilt... dan ben je zelf degene die dat moet bedenken.

Lang verhaal kort: als je snel aan de slag wil, het geen probleem vind om een nieuw framework te leren kennen en niet te beroerd bent om wat onwennige eigenschappen van een bestaand framework op de koop toe te willen nemen, dan zou ik vooral een bestaand framework kiezen. Daarnaast is er ongetwijfeld een grotere community die je kan helpen met evt. problemen.
Als je daarentegen heel pietluttig bent over hoe je je data-access wil inrichten, het geen probleem vind om daar initeel meer tijd aan kwijt te zijn, en ofwel geen lazy loading / change tracking wil, of precies weet hoe je wil dat het moet gaan werken...

...dan kan een simpele template processor misschien nog wel eens een goede uitkomst zijn

[HawVer]

EfBe schreef op maandag 23 februari 2009 @ 14:53:
[...]
V2 van EF wordt niet veel beter. Er is nog steeds geen oplossing voor grote projects (nog steeds 1canvas) en geen oplossing voor change management in distributed scenario's. Ik weet niet wat die grote groep developers aan het doen zijn de hele dag, maar als ze ook maar 10 minuten per dag hadden ingezet voor het EF dan waren ze al klaar geweest met al deze problemen.

Het is ook maar zeer de vraag of het EF uberhaupt wel gaat komen voor een distributed scenario.

In EF v2 we’re working to make the process smoother, but we’re trying to enable a variety of these scenarios so that it’s possible for the EF to work for you regardless of how you want to work. The good news is that means things are pretty flexible. The bad news is that the EF requires you to build some things on top of it to get there rather than making the whole thing work end-to-end right out of the box. We intend to get to that kind of experience as well, but don’t really expect to arrive there in v2. Specifically some of the things we intend to do in v2 are to make the APIs much easier to work with in these scenarios, but what we probably won’t do is build something that does automatic client-side change tracking out of the box. We’ll make it possible for you to create entities that can do that kind of thing. For example, we intend to make it much easier to attach a graph of entities which includes a mix of added, deleted and modified entities all in one operation. We’re also working to create a template-based code generation system which would make it very easy to customize codegen so that you could make your entities automatically do their own change tracking by modifying a template and having that tracking code generated for each of your entities—we might even work on some sample templates that do that kind of thing, but I don’t know if it will be completely baked into the product.

Het probleem met het hele EF is dat er een apart object is die de wijzigingen bijhoud. Op het moment dat ik een object verstuur ben ik de wijzigingen kwijt. Het zou veel logischer zijn als de wijzigingen onderdeel zijn van het object zodat bij het serialiseren de wijzigingen ook meegenomen worden. Tijdens de ontwerpfase is als de verkeerde keuze gemaakt. WCF bijvoorbeeld is een nieuwe techniek van microsoft die niet (zonder een boel werk) kan functioneren icm het EF. Met die keuze plaatst Microsoft zich meteen buiten de markt.

[EfBe]

HawVer schreef op woensdag 04 maart 2009 @ 11:38:
[...]
Het is ook maar zeer de vraag of het EF uberhaupt wel gaat komen voor een distributed scenario.
[...]
Het probleem met het hele EF is dat er een apart object is die de wijzigingen bijhoud. Op het moment dat ik een object verstuur ben ik de wijzigingen kwijt. Het zou veel logischer zijn als de wijzigingen onderdeel zijn van het object zodat bij het serialiseren de wijzigingen ook meegenomen worden. Tijdens de ontwerpfase is als de verkeerde keuze gemaakt. WCF bijvoorbeeld is een nieuwe techniek van microsoft die niet (zonder een boel werk) kan functioneren icm het EF. Met die keuze plaatst Microsoft zich meteen buiten de markt.

Op zich hoeft het Scott Ambler-design met een centrale session/context niet per se een nadeel te zijn, nhibernate heeft dacht ik ook een detach/attach die dan een dyn. subclass instance genereert met daarin de changes. Het probleem zit hem meer in de tunnelvisie waar die lui in zitten. De vele problemen die ze tegenkomen zijn tezamen wellicht een hoop werk, maar niet onoplosbaar en feitelijk al een paar keer opgelost door verschillende teams/mensen, maar ze komen er gewoon niet uit lijkt het wel.

[Lethalis]

Zijn er nog goede manieren om nhibernate te promoten? Of artikelen die de implementatie ervan onderschrijven?

Ik loop op mijn werk tegen wat weerstand aan.. zoals "het is niet van microsoft", "er staat geen echt bedrijf achter, het is open source", etc, etc.

Zelf heb ik nog eens naar het Entity Framework gekeken, maar dat mist zoveel in vergelijking met Nhibernate.. en ik vind die objectcontext ook onhandig

[RobIII]

Lethalis schreef op zondag 08 maart 2009 @ 14:39:
Ik loop op mijn werk tegen wat weerstand aan.. zoals "het is niet van microsoft", "er staat geen echt bedrijf achter, het is open source", etc, etc.

Mijn advies: wegwezen daar
Seriously; je moet nogal wat oogkleppen ophebben als je niet verder dan MS wil kijken (en take it from me; ik ben behoorlijk MS minded, maar zélfs ik zie dat zij niet overal goed in kunnen zijn ). En "er staat geen bedrijf achter/OSS" is natuurlijk helemaal dikke kul. Je moet dan toch behoorlijk 'ouderwets' en vastgeroest zijn om daar nog bang voor te zijn.

[whoami]

eens met RobIII.

Echter, ook NHibernate werkt op een gelijkaardige manier als EF toch; bij EF heet het 'DataContext' ofzoiets, bij NHibernate hebben ze het Session genoemd.

[Verwijderd]

whoami schreef op zondag 08 maart 2009 @ 15:41:
eens met RobIII.

note: voor veel bedrijven is OSS juist onhandig doordat je gekloot kunt krijgen met licenties. Wat doe je als je ergens een oplossing neerzet en er blijkt een bug in het OSS gedeelte te zitten. Oplossen, maar voor eigen rekening? Of voor die van de klant? Kan nogal in de papieren gaan lopen op het moment dat je grotere implementatie doet.

[beany]

Verwijderd schreef op zondag 08 maart 2009 @ 21:51:
[...]


note: voor veel bedrijven is OSS juist onhandig doordat je gekloot kunt krijgen met licenties. Wat doe je als je ergens een oplossing neerzet en er blijkt een bug in het OSS gedeelte te zitten. Oplossen, maar voor eigen rekening? Of voor die van de klant? Kan nogal in de papieren gaan lopen op het moment dat je grotere implementatie doet.

Dit vind ik toch wel een beetje onzin. Bij een OSS gedeelte heb je tenminste nog de mogelijkheid om de bug te fixen, het gestegel wie het dan gaat betalen is nog de minste zorg.

Probeer dat maar eens bij een stukje closed source software, waar je overgeleverd bent aan de genade van de ontwikkelaar.

[Lethalis]

whoami schreef op zondag 08 maart 2009 @ 15:41:
eens met RobIII.

Echter, ook NHibernate werkt op een gelijkaardige manier als EF toch; bij EF heet het 'DataContext' ofzoiets, bij NHibernate hebben ze het Session genoemd.

Dat is wel waar.. maar het werkt net iets anders, waardoor ik moeite heb met bepaalde zaken. Eigenlijk zou ik hiervoor een ander topic moeten openen, maar ik vraag af wat nou de beste manier is om je functionaliteit met het EF uit te breiden.

Bij Microsoft roepen ze meteen partial classes alsof dat de oplossing voor alles is, maar ik heb meteen bij mijn eerste project waar ik het wil gebruiken het probleem dat ik met verschillende databases werk, in die zin dat een gebruiker eerst op de hoofd database aanlogt, vervolgens kan kiezen welke database hij wil gebruiken, en daarna dus alles naar die database moet wijzen.

Dat houdt in dat ik de connectionstring mee moet geven aan de datacontext als ik hem aanmaak. Dat is op zich geen probleem, ik bedoel even een functie schrijven GetDataContext() die de juiste terug geeft, maar als ik dan vervolgens de functionaliteit zou uitbreiden met partial classes kom ik wel een beetje in de shit.

Stel je hebt een class User en ik wil een functie schrijven GetByNameAndPassword(), dan kan ik die niet zomaar aan de User class toevoegen, iig niet zonder de datacontext mee te geven.

Het enige wat wel zou werken is als ik de 'Entities' class zelf zou uitbreiden met GetUserByNameAndPassword, want dan is de datacontext immers bekend, maar dat vind ik lelijk, omdat ik dan alles daaraan zou moeten toevoegen.

Ik zoek dus eigenlijk een 'Best Practices' voor Entity Framework om dit soort dingen netjes te doen, maar kan daar eigenlijk maar weinig over vinden op internet.

Bij nhibernate gebruik ik gewoon het Repository pattern wat op hun site staat. Dat vind ik iig prettig werken, te meer omdat ik standaard functionaliteit als 'FindById' gewoon in een abstracte class kan onderbrengen. Hetzelfde zou ik graag willen doen met het EF, maar dat is mij nog niet echt gelukt en ik zie ook dat andere mensen op internet er op vastlopen.

Als iemand mij kan verblijden met een goede uitleg, of een handige url, dan zou ik kunnen overwegen om gewoon naar het EF te gaan om iedereen happy te houden. Maar voor mezelf voelt nhibernate wel beter aan, gewoon met poco's werken en zelf je mappings maken geeft mij iig genoeg controle over alles.

[Lethalis]

beany schreef op maandag 09 maart 2009 @ 08:04:
[...]
Dit vind ik toch wel een beetje onzin. Bij een OSS gedeelte heb je tenminste nog de mogelijkheid om de bug te fixen, het gestegel wie het dan gaat betalen is nog de minste zorg.

Probeer dat maar eens bij een stukje closed source software, waar je overgeleverd bent aan de genade van de ontwikkelaar.

Het probleem is meer dat er politiek bij komt kijken. Als iets mis gaat, wil je kunnen zeggen "we hebben gewoon tools gebruikt van bekend bedrijf x" ipv "we hebben iets gedownload waarvan mensen zeiden dat het goed was".

Oftewel: als ik nhibernate implementeer, en een collega van mij iets aan mijn code moet wijzigen en het daardoor in de soep loopt, omdat nhibernate net iets anders werkt dan hij verwacht, dan zal het al snel "aan nhibernate liggen" en dan krijg ik alle ellende op mijn dak.

Gebruik ik daarentegen iets van Microsoft dan kan ik gewoon zeggen dat hij zichzelf maar wat beter up to date had moeten houden en is het mijn probleem niet. Zeker als het entity framework de aangeraden oplossing van Microsoft wordt voor data access (volgens ado team blog), want dan doe ik eigenlijk gewoon iets standaards, helemaal niks bijzonders.

Met nhibernate ben ik gewoon weer die lul die per se iets anders moest kiezen.

Ik begrijp ook wel dat het allemaal nergens op slaat.. maar ik ben dit vaker en bij meer bedrijven tegen gekomen. Zeker ik, als Linux aanhanger, krijg al snel die stempel. Op mijn oude werk hebben we alle Linux servers vervangen door Windows, wat 10x zo duur was, alleen maar omdat ik de enige was die ermee om kon gaan en niemand zin had om het te leren.

Oh ja, voor de rest vind ik het juist leuk op mijn werk.. woon op 5 minuten rijden, ga bijna elke dag om 5 uur naar huis, kan voor de rest goed opschieten met mijn collega's, verdien een goed salaris, etc.. dus het is wel heel drastisch om dan te zeggen "wegwezen daar".

[HawVer]

Lethalis, je moet gaan denken aan een extra laag boven op het EF. EF is de abstractie van tabellen naar objecten en is vrij stug. De snelste manier bij EF is een verzameling classen bovenop het EF. Ik heb het op dezelfde manier als jou geprobeerd, maar dat werkt gewoon niet lekker.

[Janoz]

Ik ben niet bekend in het .NET wereldje, maar aan onze kant in het Java kamp is Hibernate toch wel 1 van de industrie standaarden. En dat ondanks dat er zogenaamd niemand achter zou staan. En als dat wel je probleem blijft, dan koop je toch LLBLGen Pro?

Trouwens. Wat gebeurt er nu wanneer er gekloot is met de inhous in elkaar gehobby-de o/r mapping?

* Janoz ziet toch wel ernstige vormen van het NIH syndroom..

[Lethalis]

MrBucket schreef op dinsdag 03 maart 2009 @ 23:19:
...gecombineerd met je eerdere opmerking dat je zelf een beetje een database-man bent, zou je kunnen doen overwegen om een template processor a la CodeSmith of MyGeneration in te zetten. Deze kunnen op basis van je databaseschema stukken tekst (C#, VB.NET en/of SQL) genereren. Dit kun je gebruiken om je entity classes, entity managers en CRUD stored procedures te genereren op basis van je tabeldefinities.

Nou ja, ik vind o/r mappers als nhibernate op zich prima en ik hoef voor CRUD ook helemaal geen stored procedures te gebruiken. Dat doe ik dan wel voor reports e.d. waar ik met veel joins en veel data krijg te maken.

Ik ga nog wel naar codesmith kijken.. al is het alleen maar om te kijken waar ik allemaal tijd mee kan besparen. Thanks voor de link!

[Lethalis]

Janoz schreef op maandag 09 maart 2009 @ 08:59:
Trouwens. Wat gebeurt er nu wanneer er gekloot is met de inhous in elkaar gehobby-de o/r mapping?

* Janoz ziet toch wel ernstige vormen van het NIH syndroom..

Dan mag degene die dat stukje heeft geprogrammeerd het oplossen.. en als die er niet is, dan gaat het dus meer tijd kosten.

Nou ja, NIH valt nog wel mee, want we gebruiken bijv. wel ComponentOne componenten en als je iets gebruikt van Microsoft mag het ook gewoon. Het is meer een soort anti open source vanuit management.

[Lethalis]

HawVer schreef op maandag 09 maart 2009 @ 08:52:
Lethalis, je moet gaan denken aan een extra laag boven op het EF. EF is de abstractie van tabellen naar objecten en is vrij stug. De snelste manier bij EF is een verzameling classen bovenop het EF. Ik heb het op dezelfde manier als jou geprobeerd, maar dat werkt gewoon niet lekker.

Waar ik een beetje moeite mee heb is ook het sessie management.

Aan de ene kant wil je niet dat je applicatie veel te maken heeft met data access, aan de andere kant is dat wel waar je de sessie bijhoudt.

Als ik namelijk in een stateless omgeving, als ASP.Net webforms, de sessie niet zou bijhouden, dan wordt het moeilijk om eerst een User object op te halen bijv, dat de wijzigen, en later weer op te slaan (iig zonder het eerst weer op te halen).

Hoe heb jij dat opgelost? Als je evt een voorbeeld projectje hebt oid, kun je dat uiteraard ook naar mij mailen

Wat ik trouwens jammer vind aan een extra laag, is dat het dan net weer is alsof ik helemaal geen tijd bespaar.. omdat ik alsnog een 'laag' aan het programmeren ben.

[EfBe]

Lethalis schreef op maandag 09 maart 2009 @ 09:04:
[...]

Dan mag degene die dat stukje heeft geprogrammeerd het oplossen.. en als die er niet is, dan gaat het dus meer tijd kosten.

Nou ja, NIH valt nog wel mee, want we gebruiken bijv. wel ComponentOne componenten en als je iets gebruikt van Microsoft mag het ook gewoon. Het is meer een soort anti open source vanuit management.

ComponentOne? Arme Lethalis . Na ComponentArt zijn dat wel de allererbarmelijkste troepcontrols die je kunt kopen.

Lethalis schreef op maandag 09 maart 2009 @ 09:01:
[...]
Nou ja, ik vind o/r mappers als nhibernate op zich prima en ik hoef voor CRUD ook helemaal geen stored procedures te gebruiken. Dat doe ik dan wel voor reports e.d. waar ik met veel joins en veel data krijg te maken.

een goede o/r mapper laat je zelf projections definieren met joins etc. zodat je ook reporting aan kunt.

[Lethalis]

EfBe schreef op maandag 09 maart 2009 @ 09:15:
[...]

1) ComponentOne? Arme Lethalis . Na ComponentArt zijn dat wel de allererbarmelijkste troepcontrols die je kunt kopen.


[...]

2) een goede o/r mapper laat je zelf projections definieren met joins etc. zodat je ook reporting aan kunt.

1) Dan begrijp je misschien ook waarom we liever zelf een grid van .Net gebruiken en uitbreiden ipv dat van C1.

Ik gebruik C1 voornamelijk voor het PDF component, zodat ik PDF documenten kan genereren en tonen vanuit ASP.Net pagina's. Leuk voor reports en prints.

2) Dat moet ik nog uitzoeken

[ Voor 13% gewijzigd door Lethalis op 09-03-2009 09:24 ]

[whoami]

Janoz schreef op maandag 09 maart 2009 @ 08:59:
Ik ben niet bekend in het .NET wereldje, maar aan onze kant in het Java kamp is Hibernate toch wel 1 van de industrie standaarden. En dat ondanks dat er zogenaamd niemand achter zou staan. En als dat wel je probleem blijft, dan koop je toch LLBLGen Pro?

Trouwens. Wat gebeurt er nu wanneer er gekloot is met de inhous in elkaar gehobby-de o/r mapping?

* Janoz ziet toch wel ernstige vormen van het NIH syndroom..

LLBLGen is imho niet de O/R mapper die het conceptueel model dat de topicstarter wil, aanbiedt.

(rare zin)

[whoami]

Lethalis schreef op maandag 09 maart 2009 @ 09:04:
[...]

Dan mag degene die dat stukje heeft geprogrammeerd het oplossen.. en als die er niet is, dan gaat het dus meer tijd kosten.

Da's toch altijd zo, los of je nu framework X of Y gebruikt ?
Als iedereen hetzelfde framework gebruikt, zal iedereen op den duur dat framework wel kennen; als jij dan iets moet aanpassen van een collega, dan zal het -indien de code niet goed gedocumenteerd is, niet duidelijk is, whatever- je altijd extra tijd kosten om te doorgronden wat die collega nu weer in elkaar geflanst heeft, ongeacht het framework dat je gebruikt.

EfBe schreef op maandag 09 maart 2009 @ 09:15:
[...]


een goede o/r mapper laat je zelf projections definieren met joins etc. zodat je ook reporting aan kunt.

Kan hoor met NHIbernate 'k Weet alleen niet of het ook met EF kan.

[ Voor 18% gewijzigd door whoami op 09-03-2009 09:33 ]

[Lethalis]

whoami schreef op maandag 09 maart 2009 @ 09:32:
[...]

Da's toch altijd zo, los of je nu framework X of Y gebruikt ?
Als iedereen hetzelfde framework gebruikt, zal iedereen op den duur dat framework wel kennen; als jij dan iets moet aanpassen van een collega, dan zal het -indien de code niet goed gedocumenteerd is, niet duidelijk is, whatever- je altijd extra tijd kosten om te doorgronden wat die collega nu weer in elkaar geflanst heeft, ongeacht het framework dat je gebruikt.

Ja, maar niemand heeft daar zin in, dus gaan mensen naar excuses zoeken waarom iets niet goed is, en met de vinger wijzen. Dat staat nog los van waar ik werk, maar dat heb je overal. Dus als je iets gebruikt wat mensen niet kennen, gaan ze al snel dat de schuld geven.

Het heeft niks te maken met welk framework nou beter is technisch gezien.. het is gewoon politiek.

[roy-t]

Misschien een leuke toevoeging maar ik ben op dit moment Pro ASP.Net 3.5 in C# 2008 aan het lezen en daar wordt dus nog bijna exclusief gebruik gemaakt van SqlConnection e.d. icm met heel veel stored procedures en natuurlijk het DataSet object.

Verbaast me trouwens wat je allemaal wel niet kunt doen met SP's

SQL:

//Procedure naam hier
@Username nvarchar(50), 
@Password nvarchar(50), 
@LastName nvarchar(50), 
@FirstName nvarchar(50), 
@Email nvarchar(50), 
@UserID int OUTPUT 
AS 
IF NOT EXISTS(SELECT Username FROM Users WHERE Username=@Username OR Email=@Email) 
 BEGIN       
        INSERT INTO Users 
        (Username, Password, LastName, FirstName, Email)         
        VALUES (@Username, @Password, @LastName, @FirstName, @Email) 
        SET @UserID = @@IDENTITY 
 END 
ELSE 
 BEGIN 
        SET @UserID = -1 
 END

Maar ze doen dus bijna alles met SPs ik weet niet of dit heel goed is (natuurlijk iets minder dynamisch) maar het werkt iig wel lekker tijdens het programmeren en alles is beschermd tegen sqlinjection (om een SP te vullen gebruik je sowieso een parameterized query)

[EfBe]

whoami schreef op maandag 09 maart 2009 @ 09:30:
[...]
LLBLGen is imho niet de O/R mapper die het conceptueel model dat de topicstarter wil, aanbiedt.
(rare zin)

Dat lijkt me onzin, tenzij TS mixed inheritance types in 1 hierarchie wil. LLBLGen Pro genereert nl. gewoon code om calls naar procs te doen (action procs of retrieval procs die dan datatable/datasets terug te krijgen) als je dat wilt, en die kun je ook als actions toevoegen aan een unitofwork (bv dat je eerst een proc called, dan een serie entities insert met dyn. sql)

whoami schreef op maandag 09 maart 2009 @ 09:32:
Kan hoor met NHIbernate 'k Weet alleen niet of het ook met EF kan.

Iedere linq enabled toolkit kan het, dus EF ook. from c in ctx.Customer select new { c.CustomerId, c.CompanyName};

[ Voor 19% gewijzigd door EfBe op 09-03-2009 09:57 ]

[Lethalis]

roy-t schreef op maandag 09 maart 2009 @ 09:52:
Maar ze doen dus bijna alles met SPs ik weet niet of dit heel goed is (natuurlijk iets minder dynamisch) maar het werkt iig wel lekker tijdens het programmeren en alles is beschermd tegen sqlinjection (om een SP te vullen gebruik je sowieso een parameterized query)

Het probleem is alleen dat je veel herhalende code krijgt in je DAL om al die procedures aan te roepen.

Het is veel sneller en makkelijker om bijv. bij Linq2entities je Users table op een designer te mikken en dat je dan automatisch vanuit je code een nieuw User object vult en via de context SaveChanges doet.

Plus dat je dan automatisch optimistic concurrency hebt, terwijl je dat anders zelf zal moeten programmeren. Het dwingt je in feite beter te programmeren door dingen uit handen te nemen.. een stored procedure is zo goed als degene die hem geschreven heeft. Zodoende kan je er heel veel verkeerd mee doen.. (denk maar aan mensen die records keihard gaan locken om iets voor elkaar te krijgen)

(anderzijds is optimistic concurrency zoals het by default door linq2sql en het EF geimplementeerd wordt een beetje crappy qua performance.. en vind ik een apart Version veld misschien wel netter, maar goed)

[ Voor 12% gewijzigd door Lethalis op 09-03-2009 10:12 ]

[roy-t]

Lethalis schreef op maandag 09 maart 2009 @ 10:05:
[...]

Het probleem is alleen dat je veel herhalende code krijgt in je DAL om al die procedures aan te roepen.

Het is veel sneller en makkelijker om bijv. bij Linq2entities je Users table op een designer te mikken en dat je dan automatisch vanuit je code een nieuw User object vult en via de context SaveChanges doet.

Plus dat je dan automatisch optimistic concurrency hebt, terwijl je dat anders zelf zal moeten programmeren. Het dwingt je in feite beter te programmeren door dingen uit handen te nemen.. een stored procedure is zo goed als degene die hem geschreven heeft. Zodoende kan je er heel veel verkeerd mee doen.. (denk maar aan mensen die records keihard gaan locken om iets voor elkaar te krijgen)

(anderzijds is optimistic concurrency zoals het by default door linq2sql en het EF geimplementeerd wordt een beetje crappy qua performance.. en vind ik een apart Version veld misschien wel netter, maar goed)

(opzich heb je met standaard sp's ook optimistic concurrency als in: laaste wint ).

Hmm maar misschien moet ik dan toch wat meer naar Linq gaan kijken (sorry voor de mini topic-kaap) ik zit waarschijnlijk nog te veel op droge select queries niveau

[HawVer]

Lethalis schreef op maandag 09 maart 2009 @ 09:11:
[...]

Waar ik een beetje moeite mee heb is ook het sessie management.

Aan de ene kant wil je niet dat je applicatie veel te maken heeft met data access, aan de andere kant is dat wel waar je de sessie bijhoudt.

Als ik namelijk in een stateless omgeving, als ASP.Net webforms, de sessie niet zou bijhouden, dan wordt het moeilijk om eerst een User object op te halen bijv, dat de wijzigen, en later weer op te slaan (iig zonder het eerst weer op te halen).

Hoe heb jij dat opgelost? Als je evt een voorbeeld projectje hebt oid, kun je dat uiteraard ook naar mij mailen

Zie volgende pagina. http://blogs.msdn.com/dsi...entity-framework-faq.aspx Bij samples staat een voorbeeld als het goed is. Het is voor mij al weer even terug.

Wat ik trouwens jammer vind aan een extra laag, is dat het dan net weer is alsof ik helemaal geen tijd bespaar.. omdat ik alsnog een 'laag' aan het programmeren ben.

Of je die laag in een partial class of in een aparte laag programmeert maakt imho niet zoveel uit. Vanuit architectuur is het niet zo gek om een aparte laag te hebben met data handling en een laag met business logic.

EfBe schreef op maandag 09 maart 2009 @ 09:15:
[...]
ComponentOne? Arme Lethalis . Na ComponentArt zijn dat wel de allererbarmelijkste troepcontrols die je kunt kopen.

offtopic:
De controls van janus moeten je ook aanspreken. Persoonlijk spreken de http://www.divelements.com/net/ sand - controls mij het meest aan. Helaas hebben we hier gekozen voor devexpress (c.q. bloatware)

[Lethalis]

Using EF in layered architectures:

http://msdn.microsoft.com/en-us/magazine/cc700340.aspx

http://community.dynamics...atorre/comments/9583.aspx

Daar kan ik op zich wel wat mee

Al is het ook even afwachten hoe betrouwbaar dit werkt.

[ Voor 36% gewijzigd door Lethalis op 10-03-2009 09:01 ]

[Lethalis]

Voor mensen die nog interesse hebben in het Entity Framework en graag tussen layers door werken heb ik een oplossing bij elkaar gezocht.

Onderstaande code is in VB.Net:

code:

Imports Microsoft.VisualBasic
Imports System.Data
Imports System.Data.Objects.DataClasses
Imports System.Data.Objects

Namespace TestModel

  Partial Public Class TestEntities

    Public Shared Sub RemoveChangeTracker(ByVal entity As IEntityWithChangeTracker)
      entity.SetChangeTracker(Nothing)
    End Sub

    Public Shared Sub SetAllModified(Of T As IEntityWithKey)(ByVal entity As T, ByVal context As ObjectContext)
      Dim stateEntry = context.ObjectStateManager.GetObjectStateEntry(entity.EntityKey)
      Dim propertyNameList = stateEntry.CurrentValues.DataRecordInfo.FieldMetadata.[Select](Function(pn) pn.FieldType.Name)
      For Each propName In propertyNameList
        stateEntry.SetModifiedProperty(propName)
      Next
    End Sub

  End Class

End Namespace

Test code:

code:

  Public Sub UpdateToy(ByVal toy As Toy)

    Using context As New TestEntities()

      ' Kill existing change tracker of entity
      TestEntities.RemoveChangeTracker(toy)

      ' Reattach entity to new context
      context.Attach(toy)

      ' Set all fields to modified
      TestEntities.SetAllModified(toy, context)

      ' Commit changes
      context.SaveChanges()

    End Using

  End Sub

En het werkt

Bronnen (met C# voorbeelden):

http://msdn.microsoft.com...e/cc700340.aspx#id0070064

http://social.msdn.micros...3-44ef-8615-5002949bea71/

Microsoft werkt overigens aan een oplossing zodat je dit niet meer zelf hoeft te doen. Al moet ik zeggen dat het allemaal wel erg twijfelachtig is en ik zeker begrijp waarom testers een No Confidence vote hebben uitgebracht.

PS:
Ik werk met VB.Net omdat het hier op kantoor verplicht is.. maar ik kom zelf uit de C++ en C# hoek. Voordat mensen erover vallen

[ Voor 6% gewijzigd door Lethalis op 11-03-2009 11:10 ]

[EfBe]

VB.NET verplicht... hell has frozen over
<ducks>

btw, die changetracking is niet zo simpel als het lijkt. Bv jij gaat een graph van customers en orders naar de client sturen, daar ga je die aanpassen (bv: customer fields aanpassen, nieuwe customer erbij, nieuwe orders erbij), en dan stuur je hem terug. DAN begint de ellende: welke customer was nieuw? welke was aangepast? Welke order was nieuw? etc. Dat is echt niet zo simpel als het lijkt in de demo code van MS en jouw simpele voorbeeld.

[ Voor 81% gewijzigd door EfBe op 11-03-2009 17:55 ]

[Janoz]

Persoonlijk blijf ik er bij dat je het verkeerde probleem aan het oplossen bent. Je hebt weinig aan het professioneler maken van de software wanneer het ontwikkelteam zelf op een hobby niveau blijft hangen.

[HawVer]

Janoz schreef op woensdag 11 maart 2009 @ 20:29:
Persoonlijk blijf ik er bij dat je het verkeerde probleem aan het oplossen bent. Je hebt weinig aan het professioneler maken van de software wanneer het ontwikkelteam zelf op een hobby niveau blijft hangen.

Dat is precies het gevoel wat ik hier ook heb. Je ben met het EF constant om de problemen heen aan het programmeren. Daar pas ik voor. Een object mapper moet mij het leven eenvoudiger maken en niet complexer.

En wat EfBe zegt is helemaal waar. Ik wil gewoon net als bij een dataset een collectie van gegevens over de lijn heen sturen. Wat ik op A. verzend moet er op B precies hetzelfde uitzien, inclusief state management etc. Op B moet ik met het EF gaan kijken naar mijn eigen (crappy) implementatie van 'wat is gewijzigd op de client'. Aan de hand van die gegevens moet ik de objecten gaan 're-attachen'. Zeker ook met het oog op één van mijn eerdere posts, in de nabije toekomst komt er niet een definitieve oplossing, is het EF voor mij passé.

(Overigens is EF in het één laags model wel erg mooi om mee te werken)

Lethalis schreef op woensdag 11 maart 2009 @ 11:01:
Microsoft werkt overigens aan een oplossing zodat je dit niet meer zelf hoeft te doen. Al moet ik zeggen dat het allemaal wel erg twijfelachtig is en ik zeker begrijp waarom testers een No Confidence vote hebben uitgebracht.

DSimmons van het ontwikkelteam heeft via mail aangegeven dat er zeker niet in de nabije toekomst een volledig oplossing komt. Het blijft dus altijd voor een deel handwerk. Het zou kunnen dat ze daar op teruggekomen zijn, maar dat lijkt me niet

[ Voor 20% gewijzigd door HawVer op 11-03-2009 23:05 ]

[Lethalis]

EfBe schreef op woensdag 11 maart 2009 @ 17:53:
VB.NET verplicht... hell has frozen over
<ducks>

Ach, ik heb nog een collega naast mij zitten die in VB6 moet programmeren.. die heeft nu gelukkig de InteropToolkit ontdekt, zodat hij .Net componenten kan gebruiken in VB6. Dit komt omdat we nog grote software pakketten hebben in VB6, waar je makkelijk langer dan 1 jaar bezig bent om de boel te converteren en dan heb je uiteindelijk iets wat in het begin meer onderhoud oplevert dan de VB6 versie.

Op zich begrijp ik dan wel dat de directeur zoiets heeft van "dat kost een hoop geld en tijd die we beter in nieuwe projecten kunnen stoppen waar we wel direct geld aan verdienen".

Maar er is een lichtpuntje.. we beginnen binnenkort aan een nieuw project waar we misschien C# mogen gebruiken, maar dat staat nog niet vast. Lijkt mij iig wel weer eens leuk.

EfBe schreef op woensdag 11 maart 2009 @ 17:53:
btw, die changetracking is niet zo simpel als het lijkt. Bv jij gaat een graph van customers en orders naar de client sturen, daar ga je die aanpassen (bv: customer fields aanpassen, nieuwe customer erbij, nieuwe orders erbij), en dan stuur je hem terug. DAN begint de ellende: welke customer was nieuw? welke was aangepast? Welke order was nieuw? etc. Dat is echt niet zo simpel als het lijkt in de demo code van MS en jouw simpele voorbeeld.

Uiteraard.. dat van mij is gewoon een fix zodat hij iig altijd alles update (althans, geen idee wat hij met relaties doet, ws niks ).

Change tracking ben je in feite kwijt.

[ Voor 37% gewijzigd door Lethalis op 12-03-2009 09:30 ]

[Lethalis]

Janoz schreef op woensdag 11 maart 2009 @ 20:29:
Persoonlijk blijf ik er bij dat je het verkeerde probleem aan het oplossen bent. Je hebt weinig aan het professioneler maken van de software wanneer het ontwikkelteam zelf op een hobby niveau blijft hangen.

Mja, maar dan moet ik dus wel met sterke argumenten komen voor nhibernate en het zo moeten kunnen uitleggen dat het geen risico met zich meebrengt (dat is het moeilijkst) en juist geld en tijd oplevert ipv kost.

[EfBe]

Lethalis schreef op donderdag 12 maart 2009 @ 09:11:
[...]
Mja, maar dan moet ik dus wel met sterke argumenten komen voor nhibernate en het zo moeten kunnen uitleggen dat het geen risico met zich meebrengt (dat is het moeilijkst) en juist geld en tijd oplevert ipv kost.

tja, het is een simpele vergelijking. OF je gaat tijd steken in het bouwen van data-access, OF je besteedt dat uit een 3rd party, wie dat ook is, net als bij UI components of bv de database. De keuze lijkt me dan logisch. Daarna ga je kijken welke 3rd party het makkelijkst aansluit bij je werkwijze en of de 3rd party tool je inderdaad werk uit handen neemt en niet je het werk gewoon op een andere manier laat doen (dus dat je nog steeds veel tijd kwijt bent).

Een tijdje geleden hebben we daar 2 powerpoints voor gemaakt: 1 voor de technical manager en 1 voor de CEO. Wellicht kun je ze gebruiken om je manager te overtuigen om uberhaupt voor een o/r mapper te gaan. http://www.llblgen.com/pages/convince.aspx

[Lethalis]

EfBe schreef op donderdag 12 maart 2009 @ 09:31:
[...]
tja, het is een simpele vergelijking. OF je gaat tijd steken in het bouwen van data-access, OF je besteedt dat uit een 3rd party, wie dat ook is, net als bij UI components of bv de database. De keuze lijkt me dan logisch. Daarna ga je kijken welke 3rd party het makkelijkst aansluit bij je werkwijze en of de 3rd party tool je inderdaad werk uit handen neemt en niet je het werk gewoon op een andere manier laat doen (dus dat je nog steeds veel tijd kwijt bent).

Een tijdje geleden hebben we daar 2 powerpoints voor gemaakt: 1 voor de technical manager en 1 voor de CEO. Wellicht kun je ze gebruiken om je manager te overtuigen om uberhaupt voor een o/r mapper te gaan. http://www.llblgen.com/pages/convince.aspx

Ik heb ze bekeken en daar kan ik wel wat mee.

Klopt het dat MS met het hele Unit Of Work pattern in feite NHibernate probeert na te apen? En dat NHibernate door het gebruik van poco's dus eigenlijk ook geen change tracking heeft over meerdere ISession's? Of hebben ze daar in het geval van Nhibernate een oplossing voor bedacht?

[ Voor 3% gewijzigd door Lethalis op 12-03-2009 11:28 ]

[EfBe]

Lethalis schreef op donderdag 12 maart 2009 @ 11:26:
[...]

Ik heb ze bekeken en daar kan ik wel wat mee.
Klopt het dat MS met het hele Unit Of Work pattern in feite NHibernate probeert na te apen? En dat NHibernate door het gebruik van poco's dus eigenlijk ook geen change tracking heeft over meerdere ISession's? Of hebben ze daar in het geval van Nhibernate een oplossing voor bedacht?

Het 'unit of work' in de vorm van een centrale session/context is bedacht door Scott Ambler: http://www.ambysoft.com/essays/mappingObjects.html
Het is in feite heel simpel van opzet: een central object creeert de entity instances en houdt de changes bij en kan zodoende dus ook queries genereren.

Er zitten grote nadelen aan deze opzet, je hebt nl altijd dat central object nodig, de entity objects zitten als het ware verbonden aan dat central object. Dit is feitelijk een raar iets, want in OOP is het zo dat een object zelf zorg draagt voor zn eigen data, en hier is dat juist niet het geval.

NHibernate gebruikt subclassing, dit houdt in dat het dynamisch een subclass genereert van de entity class en daar een instance van maakt. Dus als jij een Customer class maakt en je laadt Customer data in zo'n instance dmv nhibernate, dan geeft NHibernate jouw een instantie terug van een dynamisch gecreeerde subclass van Customer. In die subclass kan hij dus alle mogelijke logica stoppen die van belang is voor nhibernate. Wat ik begrepen heb is dat nhibernate een speciale subclass genereert wanneer je een object detached en deze kun je weer attachen en de changes migreren naar die session.

[whoami]

EfBe schreef op donderdag 12 maart 2009 @ 13:00:

NHibernate gebruikt subclassing, dit houdt in dat het dynamisch een subclass genereert van de entity class en daar een instance van maakt. Dus als jij een Customer class maakt en je laadt Customer data in zo'n instance dmv nhibernate, dan geeft NHibernate jouw een instantie terug van een dynamisch gecreeerde subclass van Customer. In die subclass kan hij dus alle mogelijke logica stoppen die van belang is voor nhibernate. Wat ik begrepen heb is dat nhibernate een speciale subclass genereert wanneer je een object detached en deze kun je weer attachen en de changes migreren naar die session.

Hmm, heb je daar ergens een linkje van ofzo ?

[EfBe]

whoami schreef op donderdag 12 maart 2009 @ 14:57:
[...]

Hmm, heb je daar ergens een linkje van ofzo ?

http://ayende.com/Blog/ar...ing-from-your-client.aspx

[Lethalis]

EfBe schreef op donderdag 12 maart 2009 @ 15:35:
[...]

http://ayende.com/Blog/ar...ing-from-your-client.aspx

http://stackoverflow.com/...e-and-sessionsaveorupdate

[ Voor 14% gewijzigd door Lethalis op 12-03-2009 16:04 ]