[.NET] LLBLGen v1.2 released (data-access tier generator)

[Verwijderd]

Na een maand zwoegen, heb ik versie 1.2 afgerond van LLBLGen, mijn open source, free, data-access tier generator voor .NET/C#/VB.NET/SQLServer

Main Features van v1.2:
• Generation of the following stored procedures in T-SQL per table: Insert, Update, Delete, SelectOne using Primary Key fields, SelectOne using UNIQUE constraints, SelectOne using non-PK identity fields and GUID columns, SelectAll, SelectAll using a Foreign Key field, DeleteAll using a Primary Key field, UpdateAll using a Foreign Key field.
• Generation of the following stored procedures in T-SQL per view: Insert and SelectAll
• Generation of .NET classes (C# or VB.NET), one per table and view, for calling the generated stored procedures, each stored procedure has one corresponding method.
• Generation of a separate ConnectionProvider class which can be used to share an open database connection among one or more generated classes to run all calls to methods of these classes in an ADO.NET transaction. Running multiple calls to data-access tier methods in one transaction, using the ConnectionProvider class is done without compromising the abstract, database-unawareness of the generated API.
• Generated classes have one public get/set property per table/view field. These properties are filled with the values of the retrieved row by the SelectOne methods.
• Extensive comment generation (C# or VB.NET) which can be used for API documentation generation.
• The T-SQL code generator and C# / VB.NET generator are very flexible and tweakable using an easy to use GUI.
• Generated .NET classes and stored procedures support NULL values, plus the generated API has boundary checks for passed values.
• .NET code generator supports COM+ serviced component features so generated classes can be used as COM+ serviced components and can use most COM+ services like object pooling and transactions
• Multiple .NET coding styles are supported (both Hungarian Style and Microsoft caMel/PasCal style).
• Very fast and database-friendly: no adjustments are made to the database selected.
• Which tables and views should be processed by LLBLGen is selectable by the user.
• Generated .NET code is optimized for garbage collection and implements the IDispose interface.
• Generated .NET code is ready for compilation and the generated T-SQL code is ready to be imported into the SQLServer database.
• Generated .NET methods have error handling code and efficient usage of resources.
• Both SQLServer 7 and SQLServer 2000 are supported (plus related MSDE versions), and where possible SQLServer 2000 functionality is used.
• All SQLServer database types are supported.

Daarnaast zijn een heel scala aan bugs gefixed

Sourcecode (11000 regels C#), Documentatie en executable zijn op te halen op:
http://www.sd.nl/software/ -> LLBLGen sectie.

Have fun!

[Nielsz]

feli
Zodra ik weer eens een VB.NET app moet maken zal ik 'm zeker gebruiken

[Verwijderd]

Super Otis.

Ik ga wat collega's die al wat langer bezig zijn met .Net er eens naar laten kijken, zal feedback doorgeven.

[Verwijderd]

Verwijderd schreef op 01 augustus 2002 @ 17:39:
Ik ga wat collega's die al wat langer bezig zijn met .Net er eens naar laten kijken, zal feedback doorgeven.

Kewl! Alle feedback is welkom

[Verwijderd]

IK ben om dit moment bezig met een prog genaamd AdressKeeper en ik ben zeker van plan om hem te gebruiken, feedback volgt...

[Glimi]

Nogmaals mijn bewondering over dit product Lijkt me dat het behoorlijk wat tijd kost.

[mulder]

Nee joh, gewoon met de DAL-wizard, 5 minuutjes

Netjes hoor, zal het zeker gebruiken, sluit precies aan bij dingen die ik onder de knie wil hebben.

[Verwijderd]

Ik heb gisteren (11-11-2002) de laatste versie van 1.x uitgebracht, met wat kleine bugfixes. LLBLGen v1.x is hierbij officieel 'beeindigd', qua ontwikkeling, maar leeft nog voort op gotdotnet.com's workspaces en wellicht sourceforge.net mocht workspaces niet aanslaan (dat zit er dik in). LLBLGen v2.x is nu in development en zal hopelijk wanneer het gereleased wordt, de hegemonie van LLBLGen binnen de .net generators voortzetten

[Verwijderd]

Verwijderd schreef op 12 november 2002 @ 09:05:
Ik heb gisteren (11-11-2002) de laatste versie van 1.x uitgebracht, met wat kleine bugfixes. LLBLGen v1.x is hierbij officieel 'beeindigd', qua ontwikkeling, maar leeft nog voort op gotdotnet.com's workspaces en wellicht sourceforge.net mocht workspaces niet aanslaan (dat zit er dik in). LLBLGen v2.x is nu in development en zal hopelijk wanneer het gereleased wordt, de hegemonie van LLBLGen binnen de .net generators voortzetten

Cool . Wat voor 'n moois kunnen we in 2.0 verwachten?
Blijf je volledig op de DAL gericht, of ga je ook richting business objects werken? Want dat is denk ik een van de weinige gebreken aan LLBLGen, je zit toch de hele tijd vrij dicht bij je DB structuur. Maar verder niks dan lof .

[Verwijderd]

- template based generation, waarbij je per sessie dus je template'theme' uitkiest
- user defined stored procedures/views generation
- de complete DAL interface moet met de generator te genereren zijn, op zeer grote specialistische sp's na, maar je moet call code voor die sp's kunnen genereren
- een basic BL layer die mbv verschillende patterns (ik wil in 1e instantie 2 typen leveren) moet kunnen worden gegenereerd. In feite is dit een facade laag op de DAL, voor beter gebruik van de data in hogere lagen van de app, plus dat je niet vastzit aan namen etc van de tables/fields. Ik wil 1 stateful en 1 stateless leveren.

Alles moet taskbased worden, dus je hebt een engine die in feite een task-executor is en (geneste) tasks uitvoert die zijn gegenereerd door de GUI. De GUI laat dus de user eerst alles uitwerken, en dan alles genereren.

Op dit moment heb ik weinig tijd ervoor, het design is wel klaar, het is alleen nu uitcoden en dat vreet uiteraard ook de nodige tijd. Op dit moment ben ik met mn universal parser bezig voor de templates, wat in feite een grote hap is voor de generator.

Wat ik per se links laat liggen is koppelingen met tools als Rational XDE en Visio, omdat wanneer je bv XDE hebt, je makkelijk daarmee je code kan genereren en niet mijn tool nodig hebt

[Scare360]

Verwijderd schreef op 12 november 2002 @ 11:46:
het design is wel klaar

Ik zou heel graag het ontwerp eens inzien. Zijn hier mogelijkheden toe?

[Verwijderd]

paulgielens schreef op 12 november 2002 @ 21:01:
[...]


Ik zou heel graag het ontwerp eens inzien. Zijn hier mogelijkheden toe?

Ik zal zo es kijken of ik wat gifjes van de visio modellen kan maken

[Verwijderd]

Here we go.
Dit zijn 4 gifs van wat visio ontwerpen en wat uitleg ervan. De rest blijft confidential, omdat de tool bijna zeker niet gratis zal zijn .

Top level:


Top level front end:


Top level task executor:


.NET Code generator


Zoals je ziet is het design database independent, en kan voor iedere database een driver worden geschreven die dus samen met LLBLGen code genereert.

[Verwijderd]

Verwijderd schreef op 12 November 2002 @ 21:43:
Here we go.
Dit zijn 4 gifs van wat visio ontwerpen en wat uitleg ervan. De rest blijft confidential, omdat de tool bijna zeker niet gratis zal zijn .

Jammer, maar wel begrijpelijk... want de hoeveelheid werk die je erin stopt is vast niet mis en logisch dat je daar wat voor terug wilt. Maar hopelijk krijg je meteen de source als je een licentie koopt, want dat is eigenlijk wel nodig voor dit soort tools...

[Verwijderd]

Verwijderd schreef op 12 november 2002 @ 22:07:
[...]

Jammer, maar wel begrijpelijk... want de hoeveelheid werk die je erin stopt is vast niet mis en logisch dat je daar wat voor terug wilt. Maar hopelijk krijg je meteen de source als je een licentie koopt, want dat is eigenlijk wel nodig voor dit soort tools...

Het is dus de bedoeling dat dmv de templates je geen sourcecode meer nodig hebt om de tool te customizen. De gui zorgt ervoor dat je wat je wilt genereren ook kan genereren op de manier zoals je dat wilt, de templates zorgen er dan voor dat het ook echt gegenereerd wordt.

Dit is wel een zeer complex vraagstuk en met name het inpassen van templates van delen van de te genereren stored proc of class tot 1 geheel is de trick

[Scare360]

opgenomen in de planning, bedankt!

[Verwijderd]

ziet er goed uit otis, je gaat dus instellingen opslaan middels xml?
ga je ook zorgen voor 'envelopes' om relaties te leggen tussen verschillende soorten DB's?
ik mis wel eens tools met de mogelijkheid om meer dan 1 DB aan te roepen

Een handig stukje open source wat ik ook gebruik met stukken uit jouw LLBGen is DataJuncture (SourceForge). Ik heb stukjes uit jouw tool omgezet in VB.NET en probeer nu ook de Turbo Pascal erin te implementeren voor Delphi 7 users.

[Verwijderd]

Instellingen worden opgeslagen middels xml, via de soap serializer. Dit is verreweg het snelst geimplementeerd en werkt altijd

De generator gaat ervan uit dat je, zoals in een normaal project, eerst je analyses en ontwerpen gemaakt hebt, en daarna je database hebt gecreeerd (de tabellen, constraints etc). De generator is in feite dus een hulp bij het programmeren/implementeren van functionaliteit: ipv het zelf in te typen, genereer je het. Dat is de simpele reden om een generator te gebruiken.

Echter, er zijn altijd limieten verbonden aan het genereren van code. 1 ervan is het focussen op 1 database voor je code, omdat ik ervan uit ga dat je database in 1 database is gestored. Normaliter is dit ook zo. Is dit niet het geval, run dan de generator voor elk type database en zet de gegeneerde classes in 1 project. veel meer relaties tussen data in meerdere databases is volgens mij niet nuttig, nuttiger is dan de data via 1 database te benaderen (bv wat kan door servers te linken in 1 sqlserver)

[Verwijderd]

Otis,

heb je wel gelijk in, maar je kan gewoon ook meedere connectionstrings in een array zetten en je generator er laten doorheen lopen, per connectie maak je een andere folder aan...
daar zat ik zelf ff mee te rommelen vorige week, omdat er een projectje was waar ik mee aan het rommelen was dat een pak gegevens haalt uit sql server en uit een online mySQL DB

[Scare360]

Ok, ik heb het nog niet in de workspace gemeld, maar ik ben bezig de optie COM specificaties te verwerken...dus de gebruiker kan een .NET DAL laag fixen welke voldoet aan de COM spec (recordsetjes enzo).

[PhoneTech]

Ik maak nu ook gebruik van LLBLGen 1.2 en het heeft verschrikkelijk veel werk uithanden genomen! En het werkt nog snel en betrouwbaar ook!

Omdat mijn database nog vaak aan veranderingen bloot staat, heb ik de sourcecode gedownload.

Deze ga ik zodanig aanpassen zodat de gegerereerde stored procedures gelijk worden geimporteerd in de database. Misschien een idee voor Versie 2???

Ik heb de output folder voor de class files al op die van mijn C# DAL project gezet dus daar zit geen probleem, maar bij de stored procedures moest ik de hele tijd de textfile inmporteren in query analyzer.. Dat hoop ik dus op te lossen door LLBLGen zo aan te passen dat hij de SQL sctipts meteen uitvoert op de DB...

Als ie af is, dan zal ik de source wel even mailen als je dat leuk vind

[Scare360]

Misschien een idee om je aan te melden in de workspaces, daar gaat de ontwikkeling van 1.2 verder als open-source project.

[PhoneTech]

En waar kan ik me dan aanmelden? En wat voor een workspaces zijn dat dan?

[Scare360]

http://www.gotdotnet.com/...65-424f-b825-455d76daba96

[Verwijderd]

PhoneTechnician schreef op 20 november 2002 @ 18:33:
En waar kan ik me dan aanmelden? En wat voor een workspaces zijn dat dan?

De workspace is voor verdere ontwikkelingen aan versie 1.x. Versie 2.0 gebeurt in house hier, niet in een open source vorm.

[Verwijderd]

Misschien meld ik me ook aan.

Hoe past een VB-programmeur in het plaatje?

[Verwijderd]

heh, de tool is in C#, dus dat wordt lastig

Paul: je hotmail account bouncete, check ff het messageboard op de workspace voor de mail)

[Verwijderd]

hmm...
dan moet ik in me eentje met de tool verder van je die ik zelf omzet naar VB

[Scare360]

Vraag me af wat de toegevoegde waarde is van een VB versie.

[JeroenB]

De grap van het hele multilanguage concept in .NET is toch juist dat als je C# stuff hebt dat je dat gewoon in je project erbij gooit en de boel instantiate in VB? Die tool zelf hoef je niet in VB te hebben.

[Verwijderd]

JeroenB schreef op 24 November 2002 @ 14:03:
De grap van het hele multilanguage concept in .NET is toch juist dat als je C# stuff hebt dat je dat gewoon in je project erbij gooit en de boel instantiate in VB? Die tool zelf hoef je niet in VB te hebben.

Nee, maar als je er iets aan wilt wijzigen of wilt toevoegen, dan is VB uitgesloten. Op zich is C# niet een nare taal om te leren en voor VB-ers juist wel een goede opstap, want je leert zo je nare VB6 streken af, die niet meer in C# kunnen.

[Verwijderd]

Verwijderd schreef op 25 november 2002 @ 07:23:
[...]

Nee, maar als je er iets aan wilt wijzigen of wilt toevoegen, dan is VB uitgesloten. Op zich is C# niet een nare taal om te leren en voor VB-ers juist wel een goede opstap, want je leert zo je nare VB6 streken af, die niet meer in C# kunnen.

Hey Otis,

Ik ben niet vies van C# hoor, af en toe werk ik ook in C#, maar het gaat niet so snel en/of makkelijk als in VB. Zeker niet als je al sinds 3.0 in VB zit

Nog ff wat, waarom voeg je geen module toe in LLBGEN die de code gelijk in een html-filetje zet als documentatie (inc. de colorcoding).

Heb anders wel een assembly liggen voor je.

[Verwijderd]

Verwijderd schreef op 25 november 2002 @ 16:03:
[...]
Ik ben niet vies van C# hoor, af en toe werk ik ook in C#, maar het gaat niet so snel en/of makkelijk als in VB. Zeker niet als je al sinds 3.0 in VB zit

Dat klopt idd, maar ik zie om me heen dat VB kloppers van weleer beter af zijn met C#, vooral bv om troep als On Error Resume Next te vermijden

Nog ff wat, waarom voeg je geen module toe in LLBGEN die de code gelijk in een html-filetje zet als documentatie (inc. de colorcoding).
Heb anders wel een assembly liggen voor je.

NDoc aanroepen is toch niet zo moeilijk ?

[Verwijderd]

Verwijderd schreef op 25 November 2002 @ 21:49:
[...]

Dat klopt idd, maar ik zie om me heen dat VB kloppers van weleer beter af zijn met C#, vooral bv om troep als On Error Resume Next te vermijden


[...]

NDoc aanroepen is toch niet zo moeilijk ?

' k was hier ff niet geweest

In VB.NET gebruik ik gewoon de Try / Catch
NDoc, eigenlijk niet gebruikt, enkel een class die gewoon de code omzet in html met colorcoding. Zal NDoc eens bekijken. Was dat niet alleen voor C# tot op heden?

[EfBe]

En zn grote broer is er nu ook

http://www.llblgen.com.

[Verwijderd]

proficiat!

Bij het binnenhalen van een volgend project, ga ik het zeker aanschaffen

[EfBe]

Bedankt!

[Verwijderd]

Ziet er leuk uit! Zo te zien ben je wat afgestapt van het DataTable idee en wat meer naar entities overgestapt... dat lijkt me wel een verbetering. Want al het gedoe met de SqlTypes maakte het werken met llblgen 1.2 een stuk moeilijker...
Voor een nieuw project zal ik hier ook zeker eens naar kijken!

_{mierenneukmodus: de screenshots op de website werken bij mij niet... ik krijg geen plaatje (nog geeneens een kruisje) te zien...}

[EfBe]

Verwijderd schreef op 08 September 2003 @ 09:37:
Ziet er leuk uit! Zo te zien ben je wat afgestapt van het DataTable idee en wat meer naar entities overgestapt... dat lijkt me wel een verbetering. Want al het gedoe met de SqlTypes maakte het werken met llblgen 1.2 een stuk moeilijker...

Ja die datatables waren niet echt werkbaar. De typed lists en typed views maken nog wel gebruik van datatables maar dan in de typed variant (dus net als in typed datasets), de rest is met custom classes gemaakt

_{mierenneukmodus: de screenshots op de website werken bij mij niet... ik krijg geen plaatje (nog geeneens een kruisje) te zien...}

Vaag, alles werkt hier wel.... hmm.

[Verwijderd]

EfBe schreef op 08 September 2003 @ 09:59:
Vaag, alles werkt hier wel.... hmm.

In de source ontbreken de plaatjes gewoon...

code:

<br clear="all" /><a name="The LLBLGen Pro designer"></a>
<h2>The LLBLGen Pro designer (click picture to enlarge)</h2>
<a href="/pages/userpics/gui_overview.gif" target="_blank">
              {heeeel veel spaties}                     </a>

Op de plek waar die spaties staan moet de <img> tag gerenderd worden lijkt me... beetje vaag...

[ Voor 23% gewijzigd door Verwijderd op 08-09-2003 10:08 . Reden: lay out werd ver****t ]

[EfBe]

Dat is wel erg weird zeg. Ik heb: <a href="/pages/userpics/gui_overview.gif" target="_blank">[img]"/pages/userpics/gui_overview_tn.gif"[/img]</a>

hmm. die html is gecached in de db, dus die wordt niet dynamisch voor jou speciaal anders opgebouwd ... erg weird. Ik zal er even naar kijken of ik ergens anders dit kan reproduceren.

wat nog wel kan is dat jullie firewall '_tn' pictures eruit filtert, omdat pornosites dat ook vaak dat soort namen gebruiken voor thumbnails.

[ Voor 42% gewijzigd door EfBe op 08-09-2003 10:20 ]

[Verwijderd]

EfBe schreef op 08 September 2003 @ 10:19:
wat nog wel kan is dat jullie firewall '_tn' pictures eruit filtert, omdat pornosites dat ook vaak dat soort namen gebruiken voor thumbnails.

Dat was het! lekker maf... ZoneAlarm blokt meer dan dat ik me bewust van was

Maar het ziet er erg strak uit moet ik zeggen! Je gebruikt de Magic library voor het docken?

Ik ga die demo zeker ff aan de tand voelen!

[EfBe]

Verwijderd schreef op 08 September 2003 @ 10:29:
[...]
Dat was het! lekker maf... ZoneAlarm blokt meer dan dat ik me bewust van was

haha Ik ga ze zo wel ff renamen, want je zal niet de enige zijn

Maar het ziet er erg strak uit moet ik zeggen! Je gebruikt de Magic library voor het docken?

Klopt! Nog wel veel bugs tegengekomen in dat ding, maar in deze opzet werkte het wel goed. Vooral de unpinning en de serialization van de window state is erg handig, je hoeft nauwelijks iets te doen om dat de beheren

Ik ga die demo zeker ff aan de tand voelen!

Succes

[Verwijderd]

170 euro is zeker niet duur, ik had verwacht dat het minimaal het 10-voudige zou gaan kosten

[EfBe]

Verwijderd schreef op 08 September 2003 @ 11:27:
170 euro is zeker niet duur, ik had verwacht dat het minimaal het 10-voudige zou gaan kosten

De concurrentie zit wel op dat prijsniveau, maar volgens mij ben je dan inderdaad te duur: de individuele developer of de kleine ontwikkelbedrijfjes, waar er erg veel van zijn, die kijken wel uit om duizenden euros te lappen voor een tool, ookal bespaart die tool ze veel tijd en dus geld .

[Scare360]

Frans denk je niet dat veel bedrijven vanwegen de runtimes afhaken? Je bent nogal afhankelijk van de runtimes in productie omgevingen en het niet open-source zijn daarvan is een risico.

Verder is de prijs misschien net iets te hoog voor prive gebruik, maar een volledig functionele demo tegen de Northwind database is dan weer perfect.

Wat ik me dan weer afvraag... heb je alles compleet remi onderzocht, geimplementeerd of zitten d'r daar bij SD code slaafjes die onder de strakke hand van F. SD werken?

[alienfruit]

Wie is de concurrentie dan

[EfBe]

paulgielens schreef op 08 September 2003 @ 22:21:
Frans denk je niet dat veel bedrijven vanwegen de runtimes afhaken? Je bent nogal afhankelijk van de runtimes in productie omgevingen en het niet open-source zijn daarvan is een risico.

DeKlarit, ORM.NET, EntityBroker, alachisoft, ze hebben allemaal runtimes in closed source. De sourcecode die gegenereerd wordt is echter wel het leeuwendeel van de functionaliteit en plugt dmv patterns in de generic closed source code (strategy pattern, DAO pattern). Sommige mensen willen inderdaad alleen alles in sourcecode. Dat kan, dan betaal je meer. Ik heb nog geen prijs voor een all-open source versie, want er zitten voor mij ook haken en ogen aan: nu lever ik de enige versies, en bij een source-versie heb je ook weer het nadeel dat mensen zelf gaan zitten wijzigen, en die wijzigingen worden dan weer teniet gedaan bij een bugfix.

Verder is de prijs misschien net iets te hoog voor prive gebruik, maar een volledig functionele demo tegen de Northwind database is dan weer perfect.

Mja, ik heb zitten rekenen, en prive is het wellicht net wat te hoog, maar goed, de hobbyprogrammeur werkt toch fijn met datasets en visual studio.net en is niet echt de doelgroep. De freelancer is al snel uit de kosten (2 uur werk besparen, dat lukt vast wel ) en vooral de kleine bedrijfjes met 2 a 3 developers zijn veel goedkoper uit, want die hoeven maar 1 license te kopen

Wat ik me dan weer afvraag... heb je alles compleet remi onderzocht, geimplementeerd of zitten d'r daar bij SD code slaafjes die onder de strakke hand van F. SD werken?

Ja, alles is compleet onderzocht, gedesigned en gebouwd door mezelf. Ik zal in de komende weken wel een blog schrijven over het bouwen van deze tool want het was wel een hele belevenis (en de grove fouten die ik gemaakt heb )

Waar ik benieuwd naar ben is of jij de tool qua techniek ook goed vindt, want je hebt veel onderzoek gedaan naar verschillende tools op dit gebied, zelf een gebouwd, en je had goede info omtrent wat wel en wat niet nuttig was in een O/R mapper.

[EfBe]

alienfruit schreef op 08 September 2003 @ 23:19:
Wie is de concurrentie dan

DeKlarit, EntityBroker, ORM.NET, TierDeveloper, pragmatier... er zijn er wel een paar hoor. Ze zitten allemaal rond de 500$ per developer, tierdeveloper zelfs rond de 1000$ per developer (!). IMHO veel te veel geld.

[PhoneTech]

Efbe.

Super tof dat LLBLGen Pro uit is!

Ben nog steeds een gelukkige gebruiker van LLBLgen 1.2, die ik trouwens wel flink heb verbouwd naar mijn eigen eisen

Het fijne wat ik van LLBLGen 1.2 vond, is de simpele gui...
Ik heb daarnet 2.0 demo gedownload, en het was wel effe schrikken...misschien een beetje overkill aan functionaliteit.

Het kan natuurlijk allemaal aan mij liggen (waarschijnlijk ook wel), maar ik weet gewoon nu nog niet in 1 oog opslag hoe ik met de gegenereerde data moet gaan werken. Met LLBLGen 1.2 was alles lekker rechttoe rechtaan...dat beviel me wel...

maar nu heb ik echt een shitload aan klasses waarvan ik de betekenis nog niet echt van begrijp

Neem me niet kwalijk, dat ik er pas een paar minuten naar heb gekeken, maar als je in de documentatie (of op de website) wat duidelijker kan beschrijven wat de verschillende klassen allemaal doen?

[EfBe]

PhoneTech schreef op 09 september 2003 @ 00:16:
Ben nog steeds een gelukkige gebruiker van LLBLgen 1.2, die ik trouwens wel flink heb verbouwd naar mijn eigen eisen

the power of open source

Het fijne wat ik van LLBLGen 1.2 vond, is de simpele gui...
Ik heb daarnet 2.0 demo gedownload, en het was wel effe schrikken...misschien een beetje overkill aan functionaliteit.

Valt wel mee hoor. Toegegeven, je hebt meer classes, maar ook veel meer functionaliteit, dus is het even zoeken hoe en wat. Daarom is er ook documentatie

Het kan natuurlijk allemaal aan mij liggen (waarschijnlijk ook wel), maar ik weet gewoon nu nog niet in 1 oog opslag hoe ik met de gegenereerde data moet gaan werken. Met LLBLGen 1.2 was alles lekker rechttoe rechtaan...dat beviel me wel...
maar nu heb ik echt een shitload aan klasses waarvan ik de betekenis nog niet echt van begrijp Neem me niet kwalijk, dat ik er pas een paar minuten naar heb gekeken, maar als je in de documentatie (of op de website) wat duidelijker kan beschrijven wat de verschillende klassen allemaal doen?

Kijk in de docs bij 'using the generated code' Daar staat stap voor stap hoe je wat moet gebruiken om iets te doen/gedaan te krijgen. Ik kom nog met een example progsel dat verschillende dingen laat zien.

[Scare360]

EfBe schreef op 08 September 2003 @ 23:26:
Waar ik benieuwd naar ben is of jij de tool qua techniek ook goed vindt, want je hebt veel onderzoek gedaan naar verschillende tools op dit gebied, zelf een gebouwd, en je had goede info omtrent wat wel en wat niet nuttig was in een O/R mapper.

Ik heb s'avond natuurlijk in Reflector de zaak bekeken, voor de dynamic query engine aangezien ik hier ook mee bezig ben geweest. Ik haal iig meteen uit de code dat je je weg weet met scanners/parsers. Vooral de uiterst "eenvoudige" oplossing voor lazy loading (wat een enorm complex probleem kan zijn) vind ik knap gevonden. De namespaces heb ik als iets minder intiutief ervaren, maar ergens heeft het ook wel weer zijn voordelen. Ik ben zelf vaak geneigd om de granualiteit uit het oog te verliezen bv:

using MyCompany.Persistence;
using MyCompany.Persistence.Collections;
using MyCompany.Persistence.Exceptions;
using MyCompany.AProduct.Domain;
using MyCompany.AProduct.Domain.Entities;
using MyCompany.AProduct.Domain.Finders;
using MyCompany.AProduct.Persistence.Mappers;
using MyCompany.AProduct.Persistence.Gateways;
using MyCompany.AProduct.Exceptions;

Verdomd jammer dat je je propertydesc'ers in de runtimes verstopt hebt en die factory ontleden maakt het er niet gemakkelijker op. Ik speel nog wat verder... ben zelf ook in crunch mode dus de avonduurtjes worden steeds korter.

Ow wat me trouwens wel opviel is dat de productiviteit ernorm verbeterd zodra je eenmaal het generatieproces onder de knie hebt. En de templates rulen! Een winform app is een kwestie van minuten geworden. Alleen constructies als:

PersonEntity
PersonEntity: CustomerEntity
PersonEntity: EmployeeEntity

tegen 1 tabel Persons is lastig (ja ja slecht db design), misschien dat ik de tool nog wat beter moet leren kennen... Als je je DB zo OOP mogelijk opzet is de output ook prima, maar als je "te gedreven" normaliseert krijg je een minder schoon domein model. Dit laatste zegt overigens niets over de tool, meer over de toepassing van generatie tegen starre db ontwerpen.

[EfBe]

paulgielens schreef op 09 September 2003 @ 11:49:
[...]
Ik heb s'avond natuurlijk in Reflector de zaak bekeken, voor de dynamic query engine aangezien ik hier ook mee bezig ben geweest. Ik haal iig meteen uit de code dat je je weg weet met scanners/parsers. Vooral de uiterst "eenvoudige" oplossing voor lazy loading (wat een enorm complex probleem kan zijn) vind ik knap gevonden.

De query engine is op zich nog niet zo optimaal als ik zou willen, maar het werkt wel vloeiend nu Die lazy loading is wel erg simpel ja. Ik ben niet erg blij met het 'property roept onderwater vrolijk routine aan', maar goed, het moet maar vanwege databinding. (Ik ben er niet blij mee omdat een 'property' een value moet teruggeven en nooit een method zou moeten aanroepen die eventueel duur zou kunnen zijn (en database access is duur ). Naja.

De namespaces heb ik als iets minder intiutief ervaren, maar ergens heeft het ook wel weer zijn voordelen. Ik ben zelf vaak geneigd om de granualiteit uit het oog te verliezen bv:

using MyCompany.Persistence;
using MyCompany.Persistence.Collections;
using MyCompany.Persistence.Exceptions;
using MyCompany.AProduct.Domain;
using MyCompany.AProduct.Domain.Entities;
using MyCompany.AProduct.Domain.Finders;
using MyCompany.AProduct.Persistence.Mappers;
using MyCompany.AProduct.Persistence.Gateways;
using MyCompany.AProduct.Exceptions;

Die namespaces zijn nodig want je kunt als user bv dezelfde naam kiezen voor een entity en een typed view (noem maar iets). Niet erg handig, maar het kan wel. Door nu namespaces daarvoor te gebruiken ontloop je dat risico, plus je zorgt er ook voor dat vrolijke lieden die templates wijzigen of namen kiezen die gelijk zijn aan een helper class, je geen errors krijgt. Maar het worden wel veel namespaces, en vooral met VB.NET gebruikers is dat wat lastiger, want VB.NET heeft de lame eigenschap om de projectnaam voor de namespace naam te plakken als de namespace naam niet begint met de projectnaam. () VB.NET ers gebruiken kennelijk niet zo vaak namespaces, dus dat het VB.NET team het maar heeft opgelost om alle code in ieder geval in de project namespace te plaatsen... ok laat ik ophouden over VB.NET voordat ik in ranten verval

Verdomd jammer dat je je propertydesc'ers in de runtimes verstopt hebt en die factory ontleden maakt het er niet gemakkelijker op. Ik speel nog wat verder... ben zelf ook in crunch mode dus de avonduurtjes worden steeds korter.

Die code heb je als het goed is (heb ik gemailed vorige week). Ja het is spitsroeden lopen met die descriptors... gek word je ervan, maar daar weet je nu alles van... Succes met crunchen

Ow wat me trouwens wel opviel is dat de productiviteit ernorm verbeterd zodra je eenmaal het generatieproces onder de knie hebt. En de templates rulen! Een winform app is een kwestie van minuten geworden.

Ja je moet even de juiste configs uitzoeken die bij je passen, eventueel aanpassen aan je wensen en dan ze gebruiken. F7 rammen en klaar

Alleen constructies als:
PersonEntity
PersonEntity: CustomerEntity
PersonEntity: EmployeeEntity

tegen 1 tabel Persons is lastig (ja ja slecht db design), misschien dat ik de tool nog wat beter moet leren kennen... Als je je DB zo OOP mogelijk opzet is de output ook prima, maar als je "te gedreven" normaliseert krijg je een minder schoon domein model. Dit laatste zegt overigens niets over de tool, meer over de toepassing van generatie tegen starre db ontwerpen.

Ja dat is een nadeel, dat eigenlijk in het relational model ligt opgesloten: met alleen DDL is het erg lastig inheritence te implementeren, en ik werk louter met DDL, niet met table contents zelf. Wellicht dat ik het later nog wel inbouw, maar echt nodig vind ik het op zich niet op dit moment.