LLBLGen Pro v3.1 released!

Yesterday we released LLBLGen Pro v3.1! Version 3.1 comes with new features and enhancements, which I'll describe briefly below. v3.1 is a free upgrade for v3.x licensees.

What's new / changed?

Designer

  • Extensible Import system. An extensible import system has been added to the designer to import project data from external sources. Importers are plug-ins which import project meta-data (like entity definitions, mappings and relational model data) from an external source into the loaded project. In v3.1, an importer plug-in for importing project elements from existing LLBLGen Pro v3.x project files has been included. You can use this importer to create source projects from which you import parts of models to build your actual project with.
  • Model-only relationships. In v3.1, relationships of the type 1:1, m:1 and 1:n can be marked as model-only. A model-only relationship isn't required to have a backing foreign key constraint in the relational model data. They're ideal for projects which have to work with relational databases where changes can't always be made or some relationships can't be added to (e.g. the ones which are important for the entity model, but are not allowed to be added to the relational model for some reason).
  • Custom field ordering. Although fields in an entity definition don't really have an ordering, it can be important for some situations to have the entity fields in a given order, e.g. when you use compound primary keys. Field ordering can be defined using a pop-up dialog which can be opened through various ways, e.g. inside the project explorer, model view and entity editor. It can also be set automatically during refreshes based on new settings.
  • Command line relational model data refresher tool, CliRefresher.exe. The command line refresh tool shipped with v2.6 is now available for v3.1 as well
  • Navigation enhancements in various designer elements. It's now easier to find elements like entities, typed views etc. in the project explorer from editors, to navigate to related entities in the project explorer by right clicking a relationship, navigate to the super-type in the project explorer when right-clicking an entity and navigate to the sub-type in the project explorer when right-clicking a sub-type node in the project explorer.
  • Minor visual enhancements / tweaks

LLBLGen Pro Runtime Framework

  • Entity creation is now up to 30% faster and takes 5% less memory. Creating an entity object has been optimized further by tweaks inside the framework to make instantiating an entity object up to 30% faster. It now also takes up to 5% less memory than in v3.0
  • Prefetch Path node merging is now up to 20-25% faster. Setting entity references required the creation of a new relationship object. As this relationship object is always used internally it could be cached (as it's used for syncing only). This increases performance by 20-25% in the merging functionality.
  • Entity fetches are now up to 20% faster. A large number of tweaks have been applied to make entity fetches up to 20% faster than in v3.0.
  • Full WCF RIA support. It's now possible to use your LLBLGen Pro runtime framework powered domain layer in a WCF RIA application using the VS.NET tools for WCF RIA services. WCF RIA services is a Microsoft technology for .NET 4 and typically used within silverlight applications.
  • SQL Server DQE compatibility level is now per instance. (Usable in Adapter). It's now possible to set the compatibility level of the SQL Server Dynamic Query Engine (DQE) per instance of the DQE instead of the global setting it was before. The global setting is still available and is used as the default value for the compatibility level per-instance. You can use this to switch between CE Desktop and normal SQL Server compatibility per DataAccessAdapter instance.
  • Support for COUNT_BIG aggregate function (SQL Server specific). The aggregate function COUNT_BIG has been added to the list of available aggregate functions to be used in the framework.
  • Minor changes / tweaks

I'm especially pleased with the import system, as that makes working with entity models a lot easier. The import system lets you import from another LLBLGen Pro v3 project any entity definition, mapping and / or meta-data like table definitions. This way you can build repository projects where you store model fragments, e.g. the building blocks for a customer-order system, a user credential model etc., any model you can think of. In most projects, you'll recognize that some parts of your new model look familiar. In these cases it would have been easier if you would have been able to import these parts from projects you had pre-created. With LLBLGen Pro v3.1 you can.

For example, say you have an Oracle schema called CRM which contains the bread 'n' butter customer-order-product kind of model. You create an entity model from that schema and save it in a project file. Now you start working on another project for another customer and you have to use SQL Server. You also start using model-first development, so develop the entity model from scratch as there's no existing database. As this customer also requires some CRM like entity model, you import the entities from your saved Oracle project into this new SQL Server targeting project. Because you don't work with Oracle this time, you don't import the relational meta-data, just the entities, their relationships and possibly their inheritance hierarchies, if any.

As they're now entities in your project you can change them a bit to match the new customer's requirements. This can save you a lot of time, because you can re-use pre-fab model fragments for new projects. In the example above there are no tables yet (as you work model first) so using the forward mapping capabilities of LLBLGen Pro v3 creates the tables, PK constraints, Unique Constraints and FK constraints for you.

This way you can build a nice repository of model fragments which you can re-use in new projects.

3 Comments

  • Great news!
    Especially the performance improvements are very useful.
    Any news on improving the time it takes to initialize/execute the first LINQtoLLBLGen query, that is quite slow especially on large models?

  • @Tudor

    The first query might suffer from the fact that dependency injection is initialized. If you use dependency injection and have discovery set to 'auto', the first time an entity type is used you'll suffer from this discovery which might take a few seconds.

    Some constructs have to be initialized as well at startup but even with large models this shouldn't take more than a few seconds. The first physical connection also takes perhaps a bit of a hit, but that's not something we can solve.

    So I suspect you use dependency injection and have discovery set to auto, correct? Our linq provider doesn't need any initialization so you'll also see this performance hit when you simply instantiate an entity, correct?

    So if it is the first physical connection which is created, the ADO.NET provider has to be initialized, and if you're using Oracle for example, it has to load the Oracle client, create the connection and store it in the pool. That's what we can't avoid (nor have influence over). If you could profile the app abit and see where the performance is choking at startup, that would be great. Please mail me with the results directly: frans AT sd DOT nl.

  • @Tudor.

    Ah that factory thing. That's indeed unavoidable. The thing is that it's done in a static ctor to avoid locking at runtime, however this means that everything is done at once. If we would create the factories on the fly, we can't use a cache (as that would require locking on the cache for multi-threading) and creating them every time is not beneficial, as it leads to more objects in memory (every collection has one instance) and slower performance.

    Does your application have a startup period? I think it does (unity also takes time), which can be dealt with with a splashscreen. You could move the initialization to that period, so you avoid the delay when the first query is executed. It's enough to create a new ElementCreator() class to trigger the initialization of the factory cache.

Comments have been disabled for this content.