LLBLGen Pro v3.0 Model first with QuickModel and more

Below I've linked a short video which demonstrates, among other things, the Quick Model feature of LLBLGen Pro v3.0. Quick Model is a feature which allows the user to specify model elements very quickly using a simple command input system combined with a visual model viewer. The scenario when this feature is ideal is when you're interviewing a Domain expert and you want to store the information you gather in a re-usable way. This feature allows you to do that in such a way that the model is immediately presented to you and the Domain expert (so s/he immediately sees if it's correct or not). Another advantage is that the model is already in your project, so if a developer has to continue with the project, you don't need a translation phase and you don't have to discuss which entities were determined during the interview, they're already in the model. All you need is a little fine tuning perhaps, using the other editors in the LLBLGen Pro designer. As the Quick Model feature is ... quick, you can type while discussing / interviewing, so the interview isn't stalled by you having to perform slow toolbox-jedi-tricks or other slow modeling wizardry.

The video creates a simple model from scratch and maps it to Oracle, creating meta-data from the model. If you pay attention at the end of the video, you will notice that in the end, not all meta-data is created (e.g. no FK constraints and no PK constraint). This is because I forgot to press the Validation button in the toolbar during the video recording () . The validation process has two steps: one validates the model and mappings and stops there, and a second step (if executed) also modifies the meta-data according to the model mapped onto it. This is a separate process as you can't keep a model in sync with meta-data in all possible model edit steps, for example foreign key constraints in the meta-data can only be created after all the required elements are available (relationship, PK fields, everything is valid).

As I'm not a video recording expert I made a mistake and accidentally deleted a frame midway, so you'll notice an error description in the log pane, while the statement causing it isn't in the video as it was on the frame I removed (as DemoBuilder recorded it a bit clumsy. Oh well..)

Please click on the screenshot below or click this link.

 

Please click the screenshot to view the small video. (opens in new window)

 

LLBLGen Pro v3.0 is scheduled to go beta in January 2010 and will support at RTM the O/R mapper frameworks: LLBLGen Pro runtime library, NHibernate 2.x, Entity Framework 1 & 4 and Linq to Sql, and more frameworks scheduled after that.

7 Comments

  • Looks GREAT but I don't want to wait until January :)

  • @Wade:
    1) You mean, you click the entity and that's the active scope? It's a nice idea. Though drag/n/drop is very slow, compared to type it in. Also imagine a model with 100 entities, you're not going to hunt down the entity you want to add a field to in a visual canvas, hence a different approach
    2) You mean, the context menu to go edit the entity from the visual entity ? It's not edited in place because it's not a WPF editor ;) (Winforms). There is alot of information though, so it has to be stored somewhere. We toyed with a lot of different setups, and all had drawbacks, especially when you want to switch between views. In the end, the info will be behind a tab somewhere.
    3) We're thinking about that but in a different approach: import of elements (entities) from other projects. So you can import one or more entities from a project you can open from disk.
    4) I don't know what you mean with default fields, do you mean like "AccountNr", which is always an int, so you can just add an Accountnr field and it's already setup? interesting.. Won't be in 3.0 but perhaps in a later version
    5) no. VS.NET is file oriented and that killed it. We then had to either create 1 tab with our editor and separate toolwindows, but we couldn't create per-entity tabs inside vs.net, as each tab is a file. So we decided not to do this. I know people want this, but frankly, it's of no use: being a vs.net add-in also means you've to work with the horrible parts of vs.net like the property grid. Instead, it's better to assign the llblgen pro editor to the project file as the default tool, and when double-clicking the project file, the designer opens. As the project file is XML in v3, it's easy to add it to a vs.net project :)

    Thanks for the feedback!

  • @Miha:
    1) yes, intellisense... :) I didnt add it right away, as it's rather tricky, and also that most names are new anyway (as you're defining elements). It's a thing to add, though I had 3 days to add this feature, as we initially cut it due to time constraints, but I found a way to do it in a very short time, so I got 3 days and build what you see in the video (the quickmodel editor + parser). Intellisense will take me at least 2 more days, and at the moment that's not what I have, perhaps in the beta-period.
    2) Nice idea, though that would require an execution engine and bigger language. This language is very very simple. But! v3 has another feature, it's called element search (see other video in an older blogpost on this blog, about creating a typedlist from search results). You can execute with it any arbitrary C#/VB.NET code over the model, so also add fields and what have you, in a loop, based on data in a file, whatever. So it's a little detour but it is possible to do that.

    DevExpress... yes some UI elements are devexpress because they allowed me to do some things like the type filter combo box is doable with devexpress but sucked in janus. Other grids are janus and not devexpress because for these purposes they were better. The tabs are still janus as they look better. The visual rendering is done by a library called IBM ILOG btw, expensive but does its job very well :) The text input which also parses the tokens (if you define the language cleverly ;)) is SyntaxEditor, so I didn't have to write a lexical analyzer, just a token parser :)

    Thanks for the feedback!

  • What would be the reason for using NHibernate or Entity Framework inside LlblGenPro? Is this about abstracting the ORM from the application?

  • @Dmitry: It's not 'inside LLBLGen Pro'. You use the designer and generate mapping files and code for these frameworks, so you don't use the llblgen pro runtime lib, just an edmx file and classes for EF and hbm.xml files + classes for nhibernate. :)

  • On number 3 and 4 above, what I am thinking is that just like you have the Entities Tree Hierarchy on the left hand side, it would be nice to have on the right hand side or the left for that matter a tree hierarchy of industry defaults for common Entities and the attributes. This way a user can either take a standard entity definition and add to it / change it or accept it as is. This would help with new designs. Also, if the list of entities were kept in a XML data dictionary that we LLBLGen Pro Users can upload / share online. This will help in international team work to build a common understanding of data attributes / entities.

    Thanks,
    Wade

  • I think , type to create/modify object model is a great idea Frans. I think , it will payoff immediately ( Both the time you guys spent and your customers ). Looking forward to have try out !

Comments have been disabled for this content.