[.NET] DAL-builder

[Verwijderd]

Hallo, ik heb al meerdere oude threads gelezen over de discussie 'Je eigen DAL-builder' tegenover bij IHibernate'. Ik werk nu bij een bedrijf waar ze al een eigen DAL-Builder hebben. Je geeft een tabel aan in een db en hoppa, je hebt je object plus alle normale sqlklassen.
Nu heb ik de opdracht gekregen om dit te verbeteren. Ik heb zeker naar NHibernate gekeken en de discussies, maar toch heb ik een aantal vragen.

* Als ik een DAL-builder maak, die vanuit een random database zijn models en accesors bouwt. Hoef ik het maar een keer te maken, elke keer selecteer je een tabel en hoppa. Maar naar wat ik gelezen heb, moet je voor NHibernate elke keer een xml-bestand maken, waarin je objecten instantieer en hun referenties en hun datatype etc.
Dit lijkt me heel dubbel, eerst maak je een db. Dan maak je een grote xml mapping. Dan heb je je objecten.
- Dus mijn vraag is, Al maak ik een goede DALBuilder ben ik klaar. Al gebruik ik NHibernate moet ik elke keer een groot xml-bestand maken. Dus wat verdien ik daarmee.

M'n tweede en laatste vraag mbt DALbuilders is: Als wij webapps maken, weten we niet alles vanaf het begin. Dus tabellen enzo worden tijdens het project toegevoegd, verwijderd en veranderd.
Mijn beeld van NHibernate is dat je eerst een xml-config maakt, vanwaaruit alles wordt opgebouwd. En dan kan je alles gebruiken. Wij voegen gewoon af en toe een map toe met extra klassen.
- Dus is NHibernate ook toepasbaar in een omgeving met veel veranderingen en sourcecontrol.

M''n laatste vraag heeft betrekking tot spring. Ik heb er echt veel over gehoord en na al die verhalen heb ik echt het gevoel dat het onmisbaar is. Ik heb ook naar spring gekeken. Ik heb me er niet genoeg in verdiept, maar heb een globale indruk gekregen( want het is grooooot ). Maar ik zal vast spring niet hebben begrepen, maar mijn indruk is: Je hebt een xml-initialisatie bestand, in dat bestand worden de implementaties van de interfaces gedeclareerd.
Dus het idee is, maak je project schaalbaar dmv gebruik van veel interfaces. Verplaats de initialisatie van deze interfaces naar een xml-bestand, zodat het scaleable is.
- Mijn vraag is dan: is dat echt de core? Dat heet gewoon goed design. Wat zit er in Spring wat er echt uitspringt, wat je nergens anders hebt, wat spring spring maakt.

[kenneth]

http://www.llblgen.com/

Ik weet niet wat je uurtarief is, maar ik betwijfel of je het voor minder dan 229 euro zelf kan.
Of werk je bij Wieluitvinders BV?

[Verwijderd]

Verwijderd schreef op zaterdag 01 april 2006 @ 23:46:
Maar naar wat ik gelezen heb, moet je voor NHibernate elke keer een xml-bestand maken, waarin je objecten instantieer en hun referenties en hun datatype etc.
Dit lijkt me heel dubbel, eerst maak je een db. Dan maak je een grote xml mapping. Dan heb je je objecten.

Volgens mij kan je ook werken met Attributes, zodat de mapping in je klasse/code zit.

[RobIII]

kenneth schreef op zondag 02 april 2006 @ 01:01:
http://www.llblgen.com/

Ik weet niet wat je uurtarief is, maar ik betwijfel of je het voor minder dan 229 euro zelf kan.
Of werk je bij Wieluitvinders BV?

Je haalt me de woorden uit de mond. Toevallig vorige week een licentie aangeschaft nadat ik de trial een goede 14 dagen had gedraaid. Ik ben er ERG over te spreken. Er zit alles op en aan wat je wil, en zit het dat niet dan kun je het eenvoudig aanpassen in templates e.d.

[ Voor 7% gewijzigd door RobIII op 02-04-2006 04:52 ]

[whoami]

Wat versta jij onder een DAL-Buidler ? Is dat in jouw ogen een code - generator ?
(N)Hibernate is geen code - generator. Bij NHibernate ga je idd xml files maken waarin je de mapping tussen je relationeel model (tabellen) en je domein model (objecten) gaat geschrijven. NHibernate gaat die mappings dan gebruiken om at - runtime sql queries te generen, en je objecten op te vullen.
Bij een O/R mapper kan je zowiezo niet rond die mapping files (of, attributen). Je moet toch op de een of andere manier aangeven welk veld er tegen welke property mapt, en hoe je de relaties in je OO model wilt maken.

Wat je ermee verdient, met een O/R mapper zoals NHibernate, is dat je zelf geen SQL meer hoeft te schrijven (stel je voor dat je 3 DBMS'en ondersteunt, dan mag je zelf 3 DAL libraries gaan schrijven, want elke DBMS heeft wel z'n eigen specifieke SQL syntax.
Een ander voordeel is, dat je zelf geen code meer hoeft te schrijven om je objecten op te vullen met de gegevens die van de DB komen.

Volgens mij kan je ook werken met Attributes, zodat de mapping in je klasse/code zit.

Volgens mij kan je dat niet bij NHibernate, maar er zijn wel O/R mappers die dat zo doen. Echter, ik persoonlijk vind dat er niet echt duidelijker op worden.

LLBLGen is helemaal iets anders dan NHibernate. Bij LLBLGen wordt er code voor jou gegenereert. Er worden classes gegenereerd op basis van een bestaand data-model. Het concept is ook helemaal anders. Waar je bij NHibernate een domain-driven design hebt, heb je bij LLBLGen eerder een entity/manager design.
Zie ook dit.
Ik denk zelf dat jij met een DAL-builder eerder iets als LLBLGen bedoelt, dan iets als NHibernate.

[EfBe]

Dank je RobIII, en Kenneth

whoami schreef op zondag 02 april 2006 @ 11:14:
LLBLGen is helemaal iets anders dan NHibernate. Bij LLBLGen wordt er code voor jou gegenereert. Er worden classes gegenereerd op basis van een bestaand data-model. Het concept is ook helemaal anders. Waar je bij NHibernate een domain-driven design hebt, heb je bij LLBLGen eerder een entity/manager design.
Zie ook dit.
Ik denk zelf dat jij met een DAL-builder eerder iets als LLBLGen bedoelt, dan iets als NHibernate.

NHibernate is ong hetzelfde als de runtime lib core van llblgen pro, alleen bij nhibernate en andere POCO o/r mappers moet je de classes zelf schrijven en ligt de filosofie eerder op 'ik maak een class en daarna pas de table', bij llblgenpro meer op 'ik heb een table en daar ga ik een class op mappen'. Klinkt wellicht hetzelfde maar is het niet zoals je correct aangeeft.

Beide wel o/r mappers, maar gebruiken verschillende uitgangspunten vwb hoe ze data benaderen en dus wat semantisch gezien je entity classes voorstellen.

In erg veel gevallen wordt er echter met een relationeel database model gestart en levert een POCO mapper je meer werk op.

[ Voor 11% gewijzigd door EfBe op 02-04-2006 11:50 ]

[alienfruit]

Kan je bij LLGen nou ook verschillende databases (i.e. DB2 en SQL Server) aanspreken en als een geheel aanspreken? Dat is bij altijd wat onduidelijk ik gebruik nu DataAbstract hiervoor, wat prima werkt voor dit doel.

[Varienaja]

Verwijderd schreef op zaterdag 01 april 2006 @ 23:46:
Ik werk nu bij een bedrijf waar ze al een eigen DAL-Builder hebben. Je geeft een tabel aan in een db en hoppa, je hebt je object plus alle normale sqlklassen.

Dat is knappe code dan!
...
Maar waarschijnlijk juist niet, omdat (gokje) jullie eigen DAL-Builder er vanuit gaat dat een object een row is in een bepaalde tabel.

Het mooie van (N)Hibernate is dat je hele complexe objecten met allerlei relaties, afhankelijkheden en overerving ook netjes in je DB kwijt kunt. Ik heb helemaal niks aan een object wat slechts een row in een database is. Dan kan ik evengoed een item in een resultset gebruiken.

Behalve dat is jouw werkwijze om vanuit tabellen objecten te genereren verkeerdom. De juiste wijze is eerst ontwerpen, dan objecten maken, objecten implementeren, unittesten maken; en pas dan kom je er aan toe om tabelstructuren te verzinnen. _{Niet dat ikzelf altijd zo keurig werk}

[RobIII]

alienfruit schreef op zondag 02 april 2006 @ 13:26:
Kan je bij LLGen nou ook verschillende databases (i.e. DB2 en SQL Server) aanspreken en als een geheel aanspreken? Dat is bij altijd wat onduidelijk ik gebruik nu DataAbstract hiervoor, wat prima werkt voor dit doel.

Als een geheel aanspreken? Alsof het 1 DB is? Ik denk dat je dan gewoon 2 projecten kunt maken en die in je code allebei gebruiken, maar ik weet niet of ik je vraag helemaal goed begrijp.

Question: What databases does LLBLGen Pro support?

Solution: At the moment, LLBLGen supports SQL Server 7/2000, MSDE 7.0/2000, Oracle 8i/9i, Oracle 10g, Firebird 1.x/Interbase 6.0, MySql 4.x, DB2 7.x/8.x and MS Access 2000/XP/2003. We do plan to release other database drivers in the future, so please check back regularly.

Varienaja schreef op zondag 02 april 2006 @ 17:36:
[...]
Behalve dat is jouw werkwijze om vanuit tabellen objecten te genereren verkeerdom. De juiste wijze is eerst ontwerpen, dan objecten maken, objecten implementeren, unittesten maken; en pas dan kom je er aan toe om tabelstructuren te verzinnen. _{Niet dat ikzelf altijd zo keurig werk}

Als je "From scratch" begint misschien wel, maar wat dacht je van bestaande projecten waarvan de database gebruikt dient te worden? Of software van andere partijen waarop je wil "aansluiten"?

[ Voor 28% gewijzigd door RobIII op 02-04-2006 17:59 ]

[kenneth]

Varienaja schreef op zondag 02 april 2006 @ 17:36:
Behalve dat is jouw werkwijze om vanuit tabellen objecten te genereren verkeerdom. De juiste wijze is eerst ontwerpen, dan objecten maken, objecten implementeren, unittesten maken; en pas dan kom je er aan toe om tabelstructuren te verzinnen. _{Niet dat ikzelf altijd zo keurig werk}

De juiste wijze? Ik dacht dat dat zwart/wit-denken inmiddels wel was uitgestorven. Zo valt er bijvoorbeeld wat voor te zeggen om eerst de unittests te maken, en dán pas de implementatie (Test-driven development).

De Ware Werkwijze bestaat niet.

[whoami]

kenneth schreef op zondag 02 april 2006 @ 18:35:
[...]

De juiste wijze? Ik dacht dat dat zwart/wit-denken inmiddels wel was uitgestorven. Zo valt er bijvoorbeeld wat voor te zeggen om eerst de unittests te maken, en dán pas de implementatie (Test-driven development).

De Ware Werkwijze bestaat niet.

Ik denk dat Varienaja het eerder had op de werkwijze mbt Domain Driven Design, waar je idd eerst je domein-model (je classes en behaviour gaat maken), en dan pas je DB model gaat ontwerpen (dat volgens het DDD paradigma een implementatie detail is).

Maar, je hebt natuurlijk wel gelijk als je zegt dat 'de' juiste werkwijze niet bestaat.

[ Voor 8% gewijzigd door whoami op 02-04-2006 18:46 ]

[Varienaja]

RobIII schreef op zondag 02 april 2006 @ 17:55:
Als je "From scratch" begint misschien wel, maar wat dacht je van bestaande projecten waarvan de database gebruikt dient te worden? Of software van andere partijen waarop je wil "aansluiten"?

Hibernate is gelukkig erg configurabel. Zelfs erg wrakkige en ondoordachte datamodellen zijn nog te mappen op keurige objecten. Maar als je de queries leesbaar wilt hebben en de mappings snapbaar kan je soms beter het datamodel aanpassen. Is dat geen optie.. nouja dan maar niet ;-)

De opmerkingen over 'de ware werkwijze' zijn terecht. Er is geen ideale en altijd werkende aanpak. Maar eerst ontwerpen, dan klassen bouwen, en (in geval van een ORM mapper als Hibernate) daarna pas aan het datamodel denken is toch wel in 99% van de gevallen de juiste denk ik.

[ Voor 3% gewijzigd door Varienaja op 02-04-2006 18:56 ]

[EfBe]

alienfruit schreef op zondag 02 april 2006 @ 13:26:
Kan je bij LLGen nou ook verschillende databases (i.e. DB2 en SQL Server) aanspreken en als een geheel aanspreken? Dat is bij altijd wat onduidelijk ik gebruik nu DataAbstract hiervoor, wat prima werkt voor dit doel.

Je kunt 1 applicatie maken en die kan verschillende databases aanspreken, per call. Dus entity X uit sqlserver halen, updaten en wegschrijven in oracle of wat voor db dan ook. Verschillende databases als 1 geheel zien kan alleen binnen 1 db type. dus verschillende catalogs binnen sqlserver of verschillende schemas binnen oracle. Je kunt dan wel inheritance hebben over catalogs/schemas heen, dus supertype mapped op een tabel in catalog A en subtype gemapped op table in catalog B.

Varienaja schreef op zondag 02 april 2006 @ 17:36:
Het mooie van (N)Hibernate is dat je hele complexe objecten met allerlei relaties, afhankelijkheden en overerving ook netjes in je DB kwijt kunt. Ik heb helemaal niks aan een object wat slechts een row in een database is. Dan kan ik evengoed een item in een resultset gebruiken.

Dat is wat iedere beetje O/R mapper kan, dus dat is niet iets wat specifiek is voor (n)hibernate.

Behalve dat is jouw werkwijze om vanuit tabellen objecten te genereren verkeerdom. De juiste wijze is eerst ontwerpen, dan objecten maken, objecten implementeren, unittesten maken; en pas dan kom je er aan toe om tabelstructuren te verzinnen. _{Niet dat ikzelf altijd zo keurig werk}

verkeerd om... ach, dat valt wel mee. Veelal analyseer je je domain in wat abstractere termen dan objecten/classes, dus bv customer entity en order entity en de relatie ertussen (customer has order, order belongs to customer etc. ). Die results gebruik je dan om je relational model op te stellen, waaruit je fysieke datamodel weer volgt, maar dat kan ook een class model zijn, maar dat hoeft dus niet. Je praat dan over hetzelfde eigenlijk, en hoe je dat fysiek weergeeft volgt daaruit, en dat is bij classes of tables eigenlijk hetzelfde.

'Eerst classes maken, dan de tables maken' is zo zwart wit, net alsof meneer Codd en Chen er niets van snapten...

[ Voor 50% gewijzigd door EfBe op 02-04-2006 23:05 ]

[BasSpruit]

Misschien overbodig, maarre... kan je geen typed datasets gebruiken? werkt toch net zo goed?