What is LLBLGen Pro?

LLBLGen Pro is a data-access solution. You use the LLBLGen Pro Designer to create the entity/domain model, define the mappings and generate source-code for one of the four supported O/R mapping frameworks: Entity Framework, NHibernate, Linq to SQL or the LLBLGen Pro Runtime Framework. You use the generated code combined with the O/R mapping framework of your choice to access your database and consume the data in that database.

What's new in LLBLGen Pro v4.0?

Designer

Visual studio integration (2010/2012). The designer is now fully integrated in VS.NET 2010 and VS.NET 2012. The stand-alone designer is also available so you can choose in which environment you want to use the designer.

Table Valued Functions support. The designer now supports Table Valued Functions, which allows you to map an entity or typed view on the resultset of the Table Valued Functions.

Action suggestions window. The designer now offers an action suggestions window, which shows what actions are recommended, given the last action of the user and the state of the project / designer. The action suggestions window helps with navigating the designer in common tasks, in case a particular feature might be hard to find.

Custom type shortcuts now have default length/precision/scale. A type shortcut can now have a default length, precision and/or scale value which is automatically used when the type shortcut is used as a field type. This allows type aliasing and easier modeling: e.g. one could define a type shortcut called 'Email' which is a type shortcut to string with a length of 150.

Rule based .NET Additional Interfaces / Namespaces. It's now possible to specify a rule using fine-grained expressions with an additional interface or additional namespace to define which elements of a given type will receive the additional interface or additional namespace. Rules can be assigned to additional interfaces / namespaces on the project level, to make it even easier to define attribute definitions in bulk for many elements in the project.

SQL Server 2012 Sequence support. The SQL Server driver now retrieves Sequence definitions from SQL Server 2012 databases, and allows you to use them in mappings. You can also create new sequences for SQL Server 2012 from within the designer, like you can for Oracle, DB2, Firebird and PostgreSql.

Char <-> String system type converter. The list of system type converters has been extended with a new char <-> string system type converter which allows you to map a char typed model element onto a DB element with type string of length(1). This is useful if you have char(1) fields in the database, which are often converted as 'string' by ADO.NET providers.

Re-scan of enum .typeimport files. It's now possible to re-scan the folders which have .typeimport files for changes to import enum types while the designer is open. This makes importing enum types much easier as the designer doesn't have to be closed and re-opened again.

The designer is now a .NET 4.0 application. No more .NET 4.0 runners needed.

LLBLGen Pro Runtime Framework

50% faster entity fetches. An extensive refactoring of the internal storage of values inside an entity instance resulted in up to 50% faster entity fetches. As entity instances don't have Entity Field instances to store their values anymore (though from the outside it will appear they will, so no code will break), memory footprints are smaller too. See http://pastebin.com/AdsKitr3 for a benchmark of how much faster the fetches are compared to v3.5 and other ORMs.

Extensible Query Result Caching. It's now possible to specify (in Linq or QuerySpec, and with minor effort also with low-level API calls) a query result cache directive to tell the runtime to cache the results for that particular query for a given amount of time. The caching system is built around an easy interface, making it easy to extend it with own cache providers for cache systems like Redis. More information...

DataScopes. The runtime framework now offers DataScopes which greatly help managing data in memory in desktop applications. More information...

Runtime Libraries are now compiled against .NET 3.5. The minimum .NET version supported by the runtime framework is now .NET 3.5.

LinqSupportClasses and QuerySpec assemblies are now merged into ORMSupportClasses. The 3 assemblies are now merged into one, SD.LLBLGen.Pro.ORMSupportClasses.dll. This makes referencing assemblies simpler.

Inlining of Value Type Definitions in the designer. It's now possible to in-line value type definitions in the designer, which makes modeling LLBLGen Pro projects simpler. More information...

TypedLists can now be fetched using QuerySpec. Before, the low-level API had to be used to fetch typedlists. In v4.0 we made it possible to fetch TypedLists using the more powerful QuerySpec query API.

True skip/offset support. It's now possible to skip n rows in a fetch without the requirement that the number of rows fetched is a multiply of n. This is in line with how Skip works in Linq. QuerySpec now has a new operator, Offset(n) which offers the same functionality.

Char <-> String(1) built-in type converter. The runtime framework now has a built-in type conversion for char <-> string(1), to make it possible to have a DB field of type char(1) be used as a .NET char typed field.

Support for OData v3. The ODataSupportClasses now support OData v3 and are now compiled against WCF Data Services v5.3.

QueryExecution Tracer. A new tracer has been added, to trace the actual query being executed. This information was already available through other tracers, but as these also emitted other information it could lead to a lot of data just to see which query was actually executed. This tracer solves that.

All low-level query API elements, including UnitofWork2, are now XML Serializable. All low-level query API classes, like predicates, relation collection, groupby collection but also the Unit of Work classes, are now serializable to XML, and as such passable to e.g. a WCF Service. This is for Adapter only.

Entity Framework support

In v4.0 of LLBLGen Pro, Entity Framework support has been updated to support Table Valued Functions on Entity Framework v5 on .NET 4.5.

Linq to Sql support

In v4.0 of LLBLGen Pro, Linq to Sql support has been updated to support Table Valued Functions.

May 30, 2010

We have been using the beta releases of LLBLGen Pro v3.0 for a few months now and it has been great getting used to some of the new features and functionality. As always the support was awesome even for the beta and on the whole it was very stable.

The full version has now been released and some of the highlights include...

Entity Framework (v1 & v4) support

NHibernate support (hbm.xml mappings & FluentNHibernate mappings)

Linq to SQL support

Allows both Model first and Database first development, or a mixture of both

January 23, 2010

As mentioned here there is a separate download for the template that is required to migrate LLBLGen Pro v2.x project files to the new format The download does include a V2xToV3Migration_readme.txt which has the usage and instructions in it which are very simple to follow.

I just ran through this process now with a project we are currently developing and the actual migration went fine, but I received an error when opening the new project file in the v3.0 Beta designer. The error (which was not copy and pasteable) was...

"In entity 'x', the field 'y' overrides an inherited field, foreign key field or field-mapped-onto-related-field, which leads to ambiguistic data-mapping."

Somehow we had managed to put a field on a subtype with the same name as the entity it was inheriting from, rather embarrassing. What should be mentioned as well is the very helpful "Possible correction action/hints" which was available when drilling down into the error, it provided 2 choices with "Go there" and "Perform" type suggestions on how to solve the problem. Click on the suggestions actually performed the suggestions which was rather awesome as well. I took this route (as I had to correct the errors with the model before the designer allowed me to refresh the metadata, which surprised me as I had already deleted the offending column from the subtype within the database).I then refreshed the Meta-data (equivalent of v2.x Catalog refresh)...

...which then cleared up the Error List except for a list of warnings regarding tables which had not been added as project elements yet which is also quite useful. I then generated the source code and tried to build only to get a whole lot of errors like..

'x.DatabaseSpecific.DataAccessAdapter' does not implement inherited abstract member 'SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase.InsertPersistenceInfoObjects(SD.LLBLGen.Pro.ORMSupportClasses.IPredicateExpression)'

'x.DataAccessAdapter' does not implement inherited abstract member 'SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase.CreateNewPhysicalDataAdapter

'x.EntityClasses.OrderStatusEntity' does not implement inherited abstract member 'SD.LLBLGen.Pro.ORMSupportClasses.EntityBase2.FieldsCustomPropertiesOfType.get'

...why? Because I didn't RTFM, so make sure you read the aptly named README1st.pdf. The actual errors though were because we were referencing the runtime libraries out of a \lib directory which is committed to source control as opposed to the GAC, copying the new versions from the v3.0 beta directory over these then fixed the above. I then however had a number of errors such as...

'x.Data.EntityClasses.ProviderEntity' does not contain a definition for 'ProviderId' and no extension method 'ProviderId' accepting a first argument of type x.Data.EntityClasses.ProviderEntity' could be found (are you missing a using directive or an assembly reference?)

...where ProviderId was the PK on an entity Provider which was a subtype of Contact. I looked at the properties available on the class and to my surprise only the supertype's PK was available, i.e. ContactId rather than ProviderId. The FK was also not visible when exploring the entity within the designer. Looked through the new Designer and Project Preferences/Properties (Which I will go into further in another post) and although I tried a few different options, I couldn't seem to change this behaviour. In the interests of getting the code working, I modified the existing code to use the PK on the supertype as needed on the subtype.

This then allowed my code to build and when running it, it seems all good with one noticeable bug thus far. The bug is regarding a property on an Anonymous Type within a LINQ query which is built by concatenating other fields on the entities retrieved by the query. Going to post on the LLBLGen forums regarding this and the above PK-FK scenario.

Overall though, even in its beta state the documentation required to install v3.0 Beta, upgrading the existing 2.x project and get it running was good and I am quite impressed thus far. Will be delving into the new features etc soon.

The long awaited beta of LLBLGen Pro v3.0 is here! This version has a completely new designer, offering (among many other features) model-first development, fine grained entity and target schema management / mapping. Support for NHibernate, Linq to Sql and Entity Framework will be added soon. Customers with a v2.x license can download the beta in the customer area, under v2.6, section 'betas'

Apart from the icon change from 2 to 3, the other changes that are immediately noticeable upon starting the design include the updated menu and tool bar…

…as well as additional output/information tabs within the status bar…

The current beta expires on 30 April 2010. The templates required to upgrade v2.x projects are available as a separate download which I am going to be giving a whirl shortly.

UPDATE 10/12/2008: Response received on LLBLGen Pro Forum post regarding FieldMappedOnManyToManyPatternsetting. The suggested new element may be included in LLBLGen Pro v3.0, but it is not guaranteed. For now we will use HideManyToManyRelationsOnCreation set to True and unhide and rename when necessary. Updated Screenshot.

UPDATE 18/03/2009: Updated to include TdlEmitTimeDateInOutPutFiles set as False. Updated Screenshot.

These are the Preferences I have just changed to now. It's not meant to be a silver bullet, as there are settings people would prefer otherwise I am sure. Obviously changing Preferences in existing Projects may cause issues, at the very least build errors, but sometimes it is worthwhile in terms of long term producitivity/ease of use.

LLBLGen Pro really allows you a great deal of flexibility so play around with the Preferences and see what works for you and the project on which you're working.

December 08, 2008

These templates allow you to generate code for Linq to Sql using any LLBLGen Pro
project. You can use the LLBLGen Pro's designer to create and maintain a project
and generate code directly from the designer using these templates. This allows
you to use the powerful catalog refreshing capabilities as well as the other
features of the LLBLGen Pro designer.

Linq to Sql's code generator isn't
template based nor does it split up the classes in one class-per-file. These
templates allow you to alter the generated code and also give you one class per
file.

April 02, 2008

LLBLGen Pro is our current data access and business logic layer of choice at emediaIT and we are now looking into using LINQ to LLBLGen Pro for future projects. It really is an awesome framework...

LLBLGen Pro generates a complete data-access tier and business objects tier for you (in C# or VB.NET), utilizing powerful O/R mapping technology and a flexible task-based code generator, allowing you to at least double your productivity!

...and I would recommend it to anyone. Their support and lead developer, Frans Bouma (Just re-awarded his MVP status), are also excellent.

We do however have issues with some of the default designer and project settings (although they do allow you to customise/set a great deal of things) in that if you have more than one relationship from one entity to another the default naming convention is...

...which leads to relationships being named .Entity_ and even .Entity__ etc if there are sufficient relationships.

I feel that the default settings should be something more like...

I am sure however that they have a good reason for have left it more customisable/open though, most likely just for greater flexibility.

March 08, 2008

For those who don't already know, Frans Bouma who is the lead developer for LLBLGen Pro (http://www.llblgen.com), which has been our choice of ORM at emediaIT for some time now is writing an excellent series of articles regarding how they are Developing Linq to LLBLGen Pro. It really is wortwhile reading for anyone that is interested in how the 2 technologies will fit together, but also if you are new to ORM and are wanting to compare the two and perhaps see where LINQ does not cover all bases, at least not yet.