Welke DAL voor .Net

[Arise]

Ik ben op zoek naar een goeie DAL technologie voor een nieuw project. Tot op heden gebruik ik de sqlhelper class uit een oudere enterprise library. Omdat deze verouderd is heb ik eens zitten rondkijken, maar ik merk toch veel problemen:

Linq2Sql : ziet er leuk uit, maar blijkbaar begraven door microsoft
Entities framework : is niet af volgens de commentaren die ik hoor
nHibernate : serieus stijle leercurve, nog veel manueel werk.
nieuwe DAAB uit enterprise library: op het eerste zicht beperkt als je geen stored proc's gebruikt, weer veel extra werk zoals zelf je update/insert/delete te gaan schrijven, wat in sqlhelper automatisch gaat via een commandbuilder...

Zijn er technologiën die jullie kunnen aanraden die aan volgende zaken beantwoorden, bedenkend dat ik vaak kleinere applicaties schrijf en daardoor complexere functionaliteit weinig/niet nodig heb.

*Redelijk snel aan te leren.
*Bespaart mij werk ipv er bij te creëeren
*Vereist niet persé stored. procs.
*Is ook naar de toekomst toe nog interessant.

Of zou het interessanter zijn nog even te behelpen met sqlhelper en volgend jaar eens te kijken naar entities framework ?

Dank voor de antwoorden.

[Woy]

Linq2Sql is leuk voor van rapid prototyping, maar IMHO niet zo geschikt voor grotere projecten. De huidige versie van het Entity framework schijnt inderdaad nog niet echt volwassen te zijn ( al heb ik er nog nooit mee gewerkt ), maar van wat ik gehoord heb komt er met VS.NET 2010 een update die een hoop van de problemen recht zou moeten trekken.

Zelf werken wij hier met NHibernate, en ik moet zeggen dat dat erg lekker werkt. Ik vind het ook wel meevallen dat je veel manueel werk moet doen. Het is wel fijn als je er zelf een project omheen bouwt wat wat randzaken voor je regelt, zodat je dat niet in elk project opnieuw moet doen.

Je zou ook nog eens kunnen kijken naar LLBLGen, die schijnt ook fijn te werken als ORM. Daar heb ik echter niet echt ervaringen mee, maar ik hoor er wel goede geluiden over.

[whoami]

Ik werk hier ook met NHibernate, en het ruled.
Er is wel een leercurve, dat kan je niet ontkennen. Je moet het Session & Flushing concept kennen, het vergt wat tijd om alle ins en outs van het mappen te kennen (je hebt tegenwoordig ook het Fluent NH project, waarbij het wellicht wel wat eenvoudiger is ipv de mappings via xml te configureren, maar ik heb het zelf nog niet gebruikt).

[Compuhair]

Ik heb voor een behoorlijk groot project samen met een aantal andere devvers NHIbernate gebruikt. Het is goed product en het was een hele vooruitgang ten opzichte van toen we nog zelf sp's schreven en code schreven om domein objecten te vullen met data uit de data laag.

Er zijn alleen twee vervelende zaken waar we tegenaan liepen:
1. N-op-N relaties zijn lastig te modelleren. Dit is met een workaround wel op te lossen (1-op-N + N-op-1), maar niet optimaal.
2. Op een gegeven moment traden er ghost-updates op. Hiermee bedoel ik dat in sommige gevallen wanneer we een object verwijderden NHibernate op het moment van een flush eerst nog een paar database records probeerde te updaten. Dit resulteerde in vage en lastige fouten.

Verder is de leercurve behoorlijk stijl.

Ik ben van plan om de nieuwste versie van Entity Framework te gaan gebruiken. Ik hoor daar tegenwoordig erg goede verhalen over.

[whoami]

Compuhair schreef op donderdag 04 februari 2010 @ 11:45:
1. N-op-N relaties zijn lastig te modelleren. Dit is met een workaround wel op te lossen (1-op-N + N-op-1), maar niet optimaal.

Misschien offtopic, maar, hoezo ? N-op-N relaties zijn juist heel makkelijk te realiseren, tenzij je extra info bij de relatie wilt opslaan.

[Compuhair]

whoami schreef op donderdag 04 februari 2010 @ 11:53:
[...]
Misschien offtopic, maar, hoezo ? N-op-N relaties zijn juist heel makkelijk te realiseren, tenzij je extra info bij de relatie wilt opslaan.

Ja dat wilde we dus

[pasz]

Vraagje. Waarvoor ga je het gebruiken ? Een webapplicatie ?

[Arise]

Het eerstkomende nieuwe project is inderdaad een kleine webapplicatie (2 maand voor 1 programmeur)

[Brainstorm]

LLblGen en nHibernate zijn zeker de eerste namen die dan bij me opkomen. Persoonlijk heb ik het meeste ervaring met de eerste, voornamelijk in webprojecten (klein en groot, qua ontwikkelduur van 1 week t/m een aantal jaar). Qua leercurve is nHibernate denk ik net iets complexer.

Wat bij llblgen sterk aan te raden is, is om de 'concepts' uit de handleiding goed door te lezen en ook echt te begrijpen. Kost misschien een uurtje of twee, maar over het algemeen kun je dan vrij snel met de designer en de gegenereerde code uit de voeten.

[pasz]

Arise schreef op donderdag 04 februari 2010 @ 13:15:
Het eerstkomende nieuwe project is inderdaad een kleine webapplicatie (2 maand voor 1 programmeur)

Okee, dan zou ik gaan voor de meest simpele DAL generator die je kan vinden.

Webapplicaties hebben meestal niet de grote overhead nodig die je vaak vindt in in populaire generators, omdat je toch stateless bent.

LLBGen is een aanrader, maar misschien al te veel van het goede, en het kost geld.

Je zou eens kunnen kijken of de mensen van http://www.mygenerationsoftware.com/ nog iets leuks hebben liggen.

Waarom ben je trouwens bang voor Stored Procedures ?

[whoami]

Hij zegt toch nergens dat hij bang is voor SP's ? Hij zegt gewoon dat hij ze liever niet gebruikt.
Ik zie trouwens niet in waarom je SP's zou gebruiken voor simpele CRUD dingen.

[pasz]

whoami schreef op donderdag 04 februari 2010 @ 15:40:
Hij zegt toch nergens dat hij bang is voor SP's ? Hij zegt gewoon dat hij ze liever niet gebruikt.
Ik zie trouwens niet in waarom je SP's zou gebruiken voor simpele CRUD dingen.

Bedankt voor je constructieve bijdrage...
Ik heb persoonlijk liever geen hybride oplossing met bijvoorbeeld zowel 'inline sql' als SP's.
Dus ook voor de CRUD gebruik ik SPs.

De meeste generatoren genereren netjes alle benodigde SPs voor je, dus die 'eis' kun je in principe laten vallen voor je DAL. Dus alleen nog op zoek naar een goede generator.

Ik vond persoonlijk deze wel aardig : http://www.devart.com/entitydeveloper/

[whoami]

pasz schreef op donderdag 04 februari 2010 @ 20:27:
[...]

Ik heb persoonlijk liever geen hybride oplossing met bijvoorbeeld zowel 'inline sql' als SP's.
Dus ook voor de CRUD gebruik ik SPs.

Waarom ? Wat is het voordeel ervan ?
Een SP vind ik meestal voor weer een extra (onnodige) 'tussenlaag' zorgen; het maakt de code er niet altijd even duidelijk op (want, wat doet die SP nu precies ... Mag je dan alweer eens verder gaan spitten, etc...).
Pas op, ik zeg niet dat SP's overbodig zijn. Ze hebben zeker hun nut, en hun toepassingsdomein. Maar voor simpele SQL statements kan je evengoed parametrized queries gebruiken.
Trouwens, met een beetje OR-mapper heb je vrijwel geen native SQL meer nodig, en als je goed bezig bent, dan stop je alle database-toegang code in DAO's / Repositories / of iets dergelijks.

Dus alleen nog op zoek naar een goede generator.

Ik heb het niet zo voor generators.

[Grijze Vos]

Ik heb een tijd geleden een keer gekeken naar nHibernate, maar dat is toch echt moeilijker doen dan noodzakelijk. LLBLGen of Linq to SQL die genereren out of the box gewoon een DAL van je database schema, veel makkelijker.

Wat is er trouwens mis met het feit dat Linq to SQL niet meer aan gewerkt wordt? Het product is gewoon af hoor, doet precies wat je nodig hebt. Een simpele O/R mapper die Linq aan kan. Vziw zitten er ook geen dodelijke bugs in die echt voor problemen zorgen oid.

Als het je 200 euro (oid) waard is kun je voor LLBLGen gaan, die is zeker de moeite waard. (Wacht dan alleen even op 3.0 die bijna uitkomt, want je moet opnieuw betalen voor elke major release.) Maar met Linq to SQL is zeker gewoon te werken hoor.

[whoami]

Grijze Vos schreef op vrijdag 05 februari 2010 @ 00:35:
Ik heb een tijd geleden een keer gekeken naar nHibernate, maar dat is toch echt moeilijker doen dan noodzakelijk. LLBLGen of Linq to SQL die genereren out of the box gewoon een DAL van je database schema, veel makkelijker.

Mja, makkelijker misschien wel, maar niet altijd dat wat je wil.

Wat is er trouwens mis met het feit dat Linq to SQL niet meer aan gewerkt wordt? Het product is gewoon af hoor, doet precies wat je nodig hebt. Een simpele O/R mapper die Linq aan kan. Vziw zitten er ook geen dodelijke bugs in die echt voor problemen zorgen oid.

Als het niet meer ondersteund wordt, geen nieuwe features bijkomen, etc... dan is het gewoon dood.

[Woy]

Linq to SQL is best leuk voor wat rapid prototyping, met een simpele database, maar in mijn ervaring heb je gewoon niet genoeg controle over wat er gebeurt in grotere applicaties.

Het is al weer een tijd geleden dat ik er naar gekeken heb, maar ik liep al snel tegen een aantal beperkingen op, waardoor we toch verder zijn gaan kijken.

[EfBe]

Grijze Vos schreef op vrijdag 05 februari 2010 @ 00:35:
Wat is er trouwens mis met het feit dat Linq to SQL niet meer aan gewerkt wordt? Het product is gewoon af hoor, doet precies wat je nodig hebt. Een simpele O/R mapper die Linq aan kan. Vziw zitten er ook geen dodelijke bugs in die echt voor problemen zorgen oid.

Als het je 200 euro (oid) waard is kun je voor LLBLGen gaan, die is zeker de moeite waard. (Wacht dan alleen even op 3.0 die bijna uitkomt, want je moet opnieuw betalen voor elke major release.) Maar met Linq to SQL is zeker gewoon te werken hoor.

Mensen die nu v2.6 kopen krijgen v3 gratis

Aan topicstarter: het hangt er in eerste instantie vanaf hoe je wilt werken: wil je vanuit entity models werken en daarmee classes maken en vanuit dat model de tables of wil je vanuit de database werken? Dat is nl. nogal een verschil en de tools die beschikbaar zijn kiezen veelal voor het 1 of het ander.

[pasz]

whoami schreef op donderdag 04 februari 2010 @ 22:08:
[...]
Waarom ? Wat is het voordeel ervan ?
Een SP vind ik meestal voor weer een extra (onnodige) 'tussenlaag' zorgen; het maakt de code er niet altijd even duidelijk op (want, wat doet die SP nu precies ... Mag je dan alweer eens verder gaan spitten, etc...).
Pas op, ik zeg niet dat SP's overbodig zijn. Ze hebben zeker hun nut, en hun toepassingsdomein. Maar voor simpele SQL statements kan je evengoed parametrized queries gebruiken.
Trouwens, met een beetje OR-mapper heb je vrijwel geen native SQL meer nodig, en als je goed bezig bent, dan stop je alle database-toegang code in DAO's / Repositories / of iets dergelijks.
[...]
Ik heb het niet zo voor generators.

whoami schreef op vrijdag 05 februari 2010 @ 00:40:
[...]
Mja, makkelijker misschien wel, maar niet altijd dat wat je wil.
[...]
Als het niet meer ondersteund wordt, geen nieuwe features bijkomen, etc... dan is het gewoon dood.

Wederom mijn complimenten voor je constructieve bijdrages.

Persoonlijk (let op, dit is mijn mening), vind ik het prettig om de SQL van de applicatie te scheiden.
Het enige wat je overbrengt zijn parameters. Het ontwikkelt gewoon wat makkelijker, ipv te zoeken in je code.
Met bepaalde frameworks wordt de SQL on-the-fly gegenereerd en op dat moment kun je alleen nog maar met je SQL-profiler meekijken.

Het lijkt me slim om ook de aanwezige MVP'er ( EfBe ) eens te raadplegen. Hij heeft wat vaker met dit bijltje gehakt.

[Grijze Vos]

Om eerlijk te zijn denk ik dat EfBe zal zeggen dat LLBLGen de shizzle is.

[EfBe]

Grijze Vos schreef op vrijdag 05 februari 2010 @ 14:55:
Om eerlijk te zijn denk ik dat EfBe zal zeggen dat LLBLGen de shizzle is.

You don't say!

Nou is dat niet altijd zo trouwens, immers, als iemand vanaf de entity model/classes wil werken, is een db oriented tool als llblgen pro v2 niet zo handig. (of EF of L2S). En vice versa natuurlijk. Ik vind dat mensen de tool moeten gebruiken die bij hun manier van denken en werken past. Als je in tabellen en SQL denkt, is een O/R mapper wellicht niet zo nuttig bv.

In v3 (nu in beta) is de designer opnieuw gemaakt en ondersteunen we ook nhibernate, linq to sql en ef, en ook model first. Dus geen discussies meer, er is altijd een framework wat past .

Voor topicstarter, deze blogposts:
http://weblogs.asp.net/fbouma/archive/2004/10/09/240225.aspx (al oud, maar IMHO nog wel wat actueel).
http://weblogs.asp.net/fb...-is-the-Domain-Model.aspx (over wat het verschil is tussen entity, entity instance, entity class, entity class instance etc. )
http://stackoverflow.com/...-persistence-layer-advice
http://www.reddit.com/r/d...entity_framework_llblgen/
http://stackoverflow.com/...hibernate-mapping-options

dan ben je wel even zoet. Dus 1e vereiste: nadenken over HOE je wilt werken. Alle O/R mappers kunnen data saven en laden, dus het gaat om wat je wilt en wat je zoekt en dan met name: wat je belangrijk vindt. Ieder O/R mapper framework is lastig in het begin en heeft een leercurve, en kan dingen niet die anderen weer wel kunnen en vice versa. Het gaat er dan ook om: welke entity 'services' zoals O/R mapper bouwers die zaken zo mooi noemen zou je willen gebruiken? Wil je security build in? Auditing? Authorization? Validation? Self-tracking entities zodat je ze makkelijk naar een .net client kunt sturen over een draadje? Wil je POCO of interesseert je dat niet?

Maak een lijstje, en zet er prioriteiten bij, dan ga je kijken welk framework het meest past bij je lijstje en die gebruik je. Of dat mijn werk is of dat van een concurrent, tja, liefst mijn werk natuurlijk maar als je je prettiger voelt bij een ander framework dan moet je dat kiezen, anders wordt het toch een lijdensweg voor je: tools gebruiken die je niet liggen is nooit leuk.

[Serpie]

Ik ben met mijn applicaties ook gestart met het entities framework, maar schoot daarin toch al snel tegen allerlei beperkingen aan en vond het gewoon niet lekker werken.

Ik heb destijds ook een aantal DAL bekeken, met als extra eis dat het gratis moest zijn dus heb ook geen betaalde opties bekeken. Ik gebruik nu subsonic voor het pakket naar alle tevredenheid en voldoet volgens mij ook aan al je gestelde voorwaarden.

[Kayshin]

Ik heb met het vorige project waaraan ik gewerkt heb met LLBLGen gewerkt en als je deze eenmaal doorhebt is dit meesterlijk! Je kan er ook gewoon LINQ op toepassen en de collection classes die gegenereerd worden zijn ook geniaal

[Arise]

Wat is jullie ervaring met tableadapters en visual studio zelf het merendeel laten genereren ?

[Grijze Vos]

Ik ben uberhaupt geen fan van de ADO.NET aanpak (inclusief het Entity Framework).

[jelmervos]

Grijze Vos schreef op woensdag 10 februari 2010 @ 16:28:
Ik ben uberhaupt geen fan van de ADO.NET aanpak (inclusief het Entity Framework).

Want?

[whoami]

Arise schreef op woensdag 10 februari 2010 @ 15:52:
Wat is jullie ervaring met tableadapters en visual studio zelf het merendeel laten genereren ?

Mja, veel werk vind ik. En toch moeilijk om al die gegevens te latten mappen met je business classes.
Als je echt OO werkt, dan ben je beter af met een OR/M zoals NHibernate (of Entity Framework - wel zelf geen ervaring met EF), of met LLBLGen. (Maar die heeft vziw een iets andere insteek).

[Alex)]

Ik heb zelf een beetje gespeeld met Castle ActiveRecord en dat vond ik er wel erg stoer uitzien. Je maakt classes aan, dat zijn dan je objecten, waar je wat attributes ([ActiveRecord], [PrimaryKey], [Property], [BelongsTo], ...) aan toevoegt en je kunt in principe je databaseschema laten genereren volgens je objects.

Castle ActiveRecord is overigens gebaseerd op nHibernate, maar de enige XML die ik heb hoeven invoeren is m'n databaseinformatie.

[whoami]

NHibernate zelf hoe je tegenwoordig in principe ook niet meer via XML te configureren. Je hebt nl. Fluent NHibernate tegenwoordig.

Ikzelf ben niet zo'n fan om m'n domain classes met dergelijke 'mapping' attributen te gaan 'bezoedelen'. Als ik naar m'n domein kijk, dan interesseert het me eigenlijk niet hoe het in de DB is opgeslagen. Althans; ik bedoel: ik heb geen behoefte om op dat moment die informatie te zien.

[ Voor 55% gewijzigd door whoami op 13-02-2010 00:35 ]

[Alex)]

Agreed. Dat is iets waar meer mensen zo over denken... al ben ik dan weer niet echt fan van Fluent NHibernate, maar dat kan ook zijn omdat ik de fluent-syntax niet snap ofzo

Een andere ORM-tool is DevExpress' eXpress Persistent Objects (XPO), dan is het enige wat je hoeft te doen te overerven van XPObject:

C#:

using DevExpress.Xpo;
...
public class Contact: XPObject {
  public string FirstName;
  public string LastName;
  public string PhoneNumber;
  public string Email;
}

C#:

Contact contact = new Contact();
contact.FirstName = "John";
contact.LastName = "Doe";
contact.Email = "[e-mail]";
contact.Save();

Wat dan weer wel jammer is, is dat XPO niet gratis is.

[whoami]

Alex) schreef op zaterdag 13 februari 2010 @ 01:11:

Wat dan weer wel jammer is, is dat XPO niet gratis is.

En dat je object model een harde referentie heeft naar die XPO library.

[P_de_B]

Waarom vind je dat erg?

[EfBe]

whoami schreef op zaterdag 13 februari 2010 @ 00:34:
NHibernate zelf hoe je tegenwoordig in principe ook niet meer via XML te configureren. Je hebt nl. Fluent NHibernate tegenwoordig.

Echt... jouw klant wil jou betalen voor het intikken van fluent nhibernate code? Als er iets is wat redundante plumbing is dan is het dat wel. Het ironische is nog dat de fluent nhibernate fans falikant tegen buddy classes zijn voor attribute based validation (op zich terecht) maar wel buddy classes gaan schrijven voor mappings (en doe dat maar eens voor een entity of 100... veel tikplezier )

Ikzelf ben niet zo'n fan om m'n domain classes met dergelijke 'mapping' attributen te gaan 'bezoedelen'. Als ik naar m'n domein kijk, dan interesseert het me eigenlijk niet hoe het in de DB is opgeslagen. Althans; ik bedoel: ik heb geen behoefte om op dat moment die informatie te zien.

De grootste fout die een developer kan maken is het aannemen dat een database weggeabstraheerd kan worden. De database is een essentieel onderdeel van je applicatie en zo belangrijk dat wellicht 40% of meer tijd doorgebracht wordt in die database. Die onder het tapijt moffelen is de hoeksteen van een mislukt project. Het jammere is dat veel developers die dat doen dan alweer op een ander project zitten en niet hun eigen puin hoeven op te ruimen.

Attribute based mappings hebben een nadeel: je kunt je code niet hergebruiken op een andere database. Aangezien er maar 1 reden is om poco te gebruiken (hergebruik van entity classes in een andere context), is het aanbrengen van attributes voor mappings op poco classes in feite dus erg onnozel (aangezien je alles met de hand intikt, en dat op zich al veel tijdverlies oplevert en je ook nog eens je werk niet kunt hergebruiken, waardoor er geen reden is om dat tikwerk uberhaupt te doen). Een XML file is dan flexibeler.

Neemt niet weg dat het denken in 'classes' in feite niet correct is, want die classes zijn niet je startpunt maar het eindpunt: ze zijn het projectieresultaat van het abstract entity model. Een 'customer' class ontstaat niet vanzelf, die maak je omdat je een abstract entity definition 'customer' hebt. Omdat je die hebt, kun je uberhaupt een mapping definieren.

Dus: Domain model -> abstract entity model -> classes + tables -> mappings. Iedere andere benadering staat gelijk aan knoeien op het niveau van "even een tabelletje met wat velden aanmaken".

whoami schreef op zaterdag 13 februari 2010 @ 09:55:
[...]
En dat je object model een harde referentie heeft naar die XPO library.

Jij moet een reference leggen met de nhibernate assembly, die komt met een tiental andere assemblies. Jouw applicatie gebruikt zeer waarschijnlijk 3rd party UI controls, die je dus ook moet referencen. Onder het mom van 'ik wil geen dependencies' ga je erg veel redundant werk doen op kosten van je klant (intikken van mapping 'code') en in the end maakt het geen zak uit, want jouw klant gaat echt het domain model niet hergebruiken en zit toch aan een serie assemblies vast in zn applicatie.

Of denk je dat je zo een o/r mapper kunt wisselen omdat je poco gebruikt? Iedere o/r mapper lekt zn features (zn 'entity services') door in je code, dat is onvermijdelijk omdat je die services juist gebruikt in je code (waarom zou je het anders gebruiken?), dit heeft als nadeel dat je code dus gekoppeld is aan de o/r mapper. Standaard voorbeeld:
myOrder.Customer = myCustomer;

In nhibernate na het statement hierboven, dit is false:
myCustomer.Orders.Contains(myOrder);

in veel andere poco o/r mappers, is dat true (en terecht, het is een reverse relationship, en wat nhibernate doet is eigenlijk niet correct, zoals wel meer in dat framework).

Er zijn er meerdere, waaronder het ghost type probleem bij lazy loaded proxies. Poco komt met een prijs, en die is in feite altijd nadelig. Het vervelende voor de klant is echter dat de developers niet geinteresseerd zijn in het bouwen van saaie code voor de klant maar veel liever stoere plumbing code schrijven, zodat het lijkt alsof ze belangrijke software aan het maken zijn. Want zeg nou zelf, na het tig-ste scherm met ditto saaie BL rules wordt het allemaal wel erg slaapverwekkend, niet?

[ Voor 27% gewijzigd door EfBe op 13-02-2010 11:13 ]

[whoami]

Niet echt veel tijd, maar toch proberen even snel te antwoorden.

EfBe schreef op zaterdag 13 februari 2010 @ 11:05:
[...]

Echt... jouw klant wil jou betalen voor het intikken van fluent nhibernate code? Als er iets is wat redundante plumbing is dan is het dat wel. Het ironische is nog dat de fluent nhibernate fans falikant tegen buddy classes zijn voor attribute based validation (op zich terecht) maar wel buddy classes gaan schrijven voor mappings (en doe dat maar eens voor een entity of 100... veel tikplezier )

Ik heb zelf nog geen fluent gebruikt; ik doe al mijn mappings in XML, en op zicht valt dit -met de intellisense- best mee.
Ik haalde gewoon fluent aan, als reactie op '... en ik heb een enkele regel xml moeten typen'.

De grootste fout die een developer kan maken is het aannemen dat een database weggeabstraheerd kan worden. De database is een essentieel onderdeel van je applicatie en zo belangrijk dat wellicht 40% of meer tijd doorgebracht wordt in die database. Die onder het tapijt moffelen is de hoeksteen van een mislukt project. Het jammere is dat veel developers die dat doen dan alweer op een ander project zitten en niet hun eigen puin hoeven op te ruimen.

Ik zeg niet dat je de database moet weg abstraheren.
Ik wil gewoon het volgende zeggen:
Als ik bezig ben met mijn domain model, dan is dat hetgeen wat me interesseert. Ik wil me dan met de business logic bezig houden, en ik hoef op dat moment niet 'afgeleid' te kunnen worden van hoe een bepaalde entity nou in de DB wordt opgeslagen.
Ikzelf ben het helemaal met je eens dat de DB verder een belangrijk onderdeel van de applicatie is. Die moet gewoon goed ontworpen worden, maar, ik wil er niet altijd mee geconfronteerd worden als ik met een stuk domein-logica bezig ben.

Jij moet een reference leggen met de nhibernate assembly, die komt met een tiental andere assemblies. Jouw applicatie gebruikt zeer waarschijnlijk 3rd party UI controls, die je dus ook moet referencen. Onder het mom van 'ik wil geen dependencies' ga je erg veel redundant werk doen op kosten van je klant (intikken van mapping 'code') en in the end maakt het geen zak uit, want jouw klant gaat echt het domain model niet hergebruiken en zit toch aan een serie assemblies vast in zn applicatie.

Ik heb nergens gezegd dat ik geen dependencies wil in mijn applicatie.
Echter, ik wil wel mijn project waar mijn domain classes zich bevinden 'zo schoon mogelijk houden'. Daar wil ik liever geen dependency met de O/R mapper bv, omdat de kans bestaat dat je dan toch gaat verleid worden om bepaalde data-access code rechtstreeks in je domain classes te gaan schrijven.
Ik stop m'n domain classes meestal in een eigen DLL, samen met de interface definities van de repositories (die horen m.i. bij het model).
En dan heb ik daarnaast een andere DLL met bv een NHibernate implementatie van mijn repository interfaces. Op die manier kan ik trouwens gemakkelijk andere implementaties gaan maken van mijn repositories voor mijn unit-tests bv.

Of denk je dat je zo een o/r mapper kunt wisselen omdat je poco gebruikt? Iedere o/r mapper lekt zn features (zn 'entity services') door in je code, dat is onvermijdelijk omdat je die services juist gebruikt in je code (waarom zou je het anders gebruiken?), dit heeft als nadeel dat je code dus gekoppeld is aan de o/r mapper. Standaard voorbeeld:
myOrder.Customer = myCustomer;

Nee, ik besef heel goed dat je de O/R mapper niet zomaar kunt wisselen. En ik vraag me trouwens ook af waarom je dat zou willen doen ?

In nhibernate na het statement hierboven, dit is false:
myCustomer.Orders.Contains(myOrder);

Waarom zou dat in NHibernate false returnen ? Dat hangt m.i. toch gewoon af van de implementatie van je Equals() en GetHashCode methods ?
EDITIk had de regel daarboven niet gezien. Tja, dan nog hangt het af van de implementatie van die property. In NHibernate zal je -indien je wil dat dat statement true returned- idd zelf de nodige logica in die prperty setter moeten gaan schrijven ...

in veel andere poco o/r mappers, is dat true (en terecht, het is een reverse relationship, en wat nhibernate doet is eigenlijk niet correct, zoals wel meer in dat framework).

Er zijn er meerdere, waaronder het ghost type probleem bij lazy loaded proxies. Poco komt met een prijs, en die is in feite altijd nadelig. Het vervelende voor de klant is echter dat de developers niet geinteresseerd zijn in het bouwen van saaie code voor de klant maar veel liever stoere plumbing code schrijven, zodat het lijkt alsof ze belangrijke software aan het maken zijn. Want zeg nou zelf, na het tig-ste scherm met ditto saaie BL rules wordt het allemaal wel erg slaapverwekkend, niet?

Sure, dat framework heeft zeker zijn minpunten, net zoals ieder framework dat heeft. Maar, tot op dit moment voldoet het voor mij, en kan ik er redelijk goed mee overweg. Het neemt werk uit handen, die tijd kan ik besteden aan de code waar het echt om draait.
owja, die lazy loaded proxies van NHibernate, die schakel ik altijd uit. Dat is echt het eerste wat ik doe.

[OMX2000]

Ik zou je graag Subsonic willen aanraden, maar in mijn ogen is alleen 2.x stabiel. De nieuwe 3.x ondersteund Linq maar is niet stabiel.

De huidige Entity Framework is het net niet. EF4 ziet er tot nu toe veelbelovend uit.

nHibernate hoor ik goede dingen over, maar heb ik niet mee gewerkt. Om een of andere reden krijg ik mezelf niet zover om het te gaan leren gebruiken.

LLBLGen heb ik nog niet gebruikt, maar hoor ik ook hele goede dingen over. (Ik zou niet durven om Efbe tegen te gaan spreken).

Linq2SQL, tja het doet 't. Maar is end of life...

Ik ben van het type dat databases gewoon mijn data moeten opslaan... Geen gezeur. Ik weet dat je een database niet weg moet abstraheren, maar ik irrititeer me mateloos aan het feit dat we zoveel code moeten schrijven om fatsoenlijk met onze data om kunnen gaan.

Waar ik zelf nog wel naar wil kijken zijn object georienteerde databases (bijv. http://www.db4o.com/). Gewoon om te kijken of het bevalt.