LLBLGen Pro screenshot

Apparantly I changed this blog posting instead of posting a new one, therefor this posting seems changed, it's not. :)

Below is a screenshot of the application, LLBLGen Pro, I've been working on for the past 6 months. LLBLGen Pro is the big brother of the DAL generator LLBLGen and generates a complete O/R mapper.


Click to enlarge

At the left you see the entities found automatically by the tool and all the relationships which are detected and added automatically (in other words: you add all these entities and their relationship definitions with 2(!) mouseclicks). In the middle you see the current state of the entity definition editor (not finished yet). Any change made is reflected directly in the project explorer at the left, everything related is updated, including the relations. At the right you see the catalog explorer, which lets you browse through all the schemas in the catalog of the project, including all tables, fields, stored procedures, resultsets and views.

LLBLGen Pro is released later this summer.

12 Comments

  • Thanks :) Most of the work done is behind the scenes, this is the first time I can actually show something that is visually attractive and somewhat interesting. :)

  • Very nice UI. Is that the Magic library from Cronwood?

  • Yes, that's the magic library. I haven't used all of its power though, but it is a very handy library for dynamic gui building, you can create powerful gui's in no time. :)

  • Yeah, I've done some prototyping with it and it's a very nice package for the price (free!).

  • It is looking great..


    Will we see any beta's or opportunities to test :-)





    Keep up the good work

  • There will be a short beta cycle of course :) I haven't decided yet if that will be a closed beta or an open beta. Of course there will be a trial version when it's released :)

  • Senkwe Chanda: :) I'll do everything I can to make the price as low as possible. It will already have a site license instead of a per-seat license, so you pay 1 price and all the developers in your department can use the tool. It will be around 150-170 euro.

  • Exciting, "generates a complete O/R mapper framework" is just what I wanted to know! I hope that our discussions about OR Mapping will be expressed in tool supremacy!





    Heads up!





    ps: What happens with heavily normalised models? Is your tool "smart enough" to let the end user be the director of what to do with what in contradiction to many, many commercial tools out there?

  • "What happens with heavily normalised models? Is your tool "smart enough" to let the end user be the director of what to do with what in contradiction to many, many commercial tools out there?"


    I know what you are refering to :) but I kept the 1 table per entity restriction. However, it shouldn't be a problem, here is why: at the left you see f.e. a relation between employee and customer, over the entity order, a m:n relation. The tool finds these relations which are not obvious to the user. ('orders' is not an intermediate table between the employee-customer relation, the relation is created using 2 1:n relations).





    It is possible to navigate from one entity to any other entity in the system, using the relations. The code generated will embed as much logic as possible to make you navigate/retrieve related entities from any entity you currently have an instance of. So heavily normalized databasemodels are not a problem, you can navigate to any related object without a problem.





    Not in the screenshot, because I have to create the designers yet, are the typed lists. These are read-only typed datatables based on entity definitions, which can span more than 1 table/entity, f.e. all orders with the customer fields joined with every row. So for data-retrieval, where bulk data has to be retrieved which spans more than 1 table, you can define typed lists, and the typed list code embeds rich logic for filtering and clever instantiation.





    Every entity definition has also a typed collection (hi mr. Fowler!) which embeds logic to work on groups of entities directly in the persistent storage or in the collection itself (and is bindable too :))





    I'm pretty sure that on the DML front, you can work easy with the entities and the relations between the entities (plus the dynamic query engine and the filters you can define to retrieve groups of objects also f.e via filters on related objects.), and on the data retrieval front, you can work with indivitual entities, the entity collections or with the typed lists.





    I also implemented stored proc execution as a bonus for people who have stored procs they want to embed (select sp's only).

  • (oh, the typed lists use the dynamic query engine and you can f.e. define a dynamic query using the same logic in your own code if you like. Yuo then can retrieve the data in a normal datatable, but the overall flexibility is there. ).

  • Looking good! I can't wait. Just a reminder to take special care for making the dev model of this work well for multiple developers using source control and such.

  • It will generate sourcecode in a directory, not overwriting readonly files. Therefor, ideally you'll do this: check out the files, generate new code, overwriting the files, check in the files again. There are a number of sourcecontrol systems and I can't support them all.





    The whole idea is that the generated code is an assembly you work with, thus the code should be compiled as a single assembly, and be referenced from own code, you also don't edit generated code, you derive from the generated code. Therefore, source control misery is limited to a bare minimum.

Comments have been disabled for this content.