Features

LLBLGen Pro has a task-based code generator framework, which uses task-performing assemblies to perform task definitions, called task performers. One of the shipped task performers is a template parser/interpreter which produces code using the template set you specify. All customers have access to the SDK which contains the full source code for all shipped task performers, information how to produce your own task performers and, for example, how to extend the template language or write your own templates. Another task performer can handle templates written in C# / VB.NET and offers flexible access to every object in the loaded LLBLGen Pro project. Customers have access to our free Template Studio IDE for creating / editing / testing templates and templatesets.

The generated code is set up to be performing well in every scenario due to its merely stateless nature. The generated code has full support for connection pooling and connection control. There are different ways to retrieve the same data, which allows you to choose between a join in one scenario and a subquery in another, and thus allowing you to opt for the best query for the situation (a lot of data/not a lot of data).

LLBLGen Pro starts from the relational model / schema. This is ideal for creating a .NET layer for a legacy database already in use in your organization. Also if your relational model/schema lacks some constructs, like foreign keys or primary keys, the system is very flexible in allowing you to add these constructs in the designer.

Custom properties are name-value pairs (both strings) which are generated as a static hashtable into the code and which can be defined on: Project, Entity, Entity field, Typed List, Typed List field, Typed View, Typed View field and stored procedure. LLBLGen Pro will pull the initially name-value pairs defined with each database object out of the schema. For example, in SqlServer these are defined as Extended Properties. You can add your own as well which you can utilize at runtime for example to generate a label text for a textbox which is bound to a particular entity field. You can also use these custom properties in your own templates to generate documentation or control the generation process.

LLBLGen Pro doesn't require any special constructs in your relational model nor extra tables or columns. No locks are hold/set at runtime or during a transaction, other than the locks set by the RDBMS itself. All mapping data is contained in memory at runtime. No modifications are performed at any time to your relational model.

Entities, which are elements mapped onto tables or views in your catalog(s)/schema set. All, or a subset of the fields in a table or view are mapped on fields in an entity. An entity can be a subtype of another entity, through inheritance, and in which it derives from its supertype the supertypes fields, relations etc. Furthermore an entity has also fields mapped on its relations, so for example you can have the field 'Orders' mapped onto the relation Customer - Order in the entity 'Customer'. Customer.Orders returns all Order entity objects in a collection filtered on that customer. Order.Customer returns a single customer entity object, related to that order entity. Entities and all the relations between them (1:1, 1:n, m:1 and m:n) are determined automatically from a catalog/schema set. You can add your own relations in the designer, for example to relate an entity mapped onto a table to an entity mapped onto a view or when there are no foreign keys defined in the database schema. You can map as much entities on a table/view as you want.
Typed Lists are read-only lists based on a subset of fields from one or more entities which have a relation (1:1, 1:n or m:1), for example a typed list CustomerOrder with a subset of the fields from the entities Customer and Order.
Typed Views are read-only view definitions which are 1:1 mapped on views in the catalog/schema set.
Stored Procedure calls are call definitions to existing stored procedures. This way you can embed existing stored procedures in your code and you don't lose investments in current applications with stored procedures (SelfServicing) Per entity type an entity collection is defined, which sports a rich set of functionality to work with one or more entities of the entity type the collection is related to, directly in the database (for example CustomerCollection works on Customer entities, directly in the database or in the collection).

LLBLGen Pro supports three types of inheritance:

• Complete hierarchy mapped onto a single table. In LLBLGen Pro this is called TargetPerEntityHierarchy. This is the inheritance type which is very easy to implement and therefore supported by most O/R mappers.
• Every type in a hierarchy mapped onto its own table, no discriminator column. In LLBLGen Pro this is called TargetPerEntity. This inheritance type is hard to implement, most O/R mappers fall back to option 3.
• Every type in a hierarchy mapped onto its own table, with discriminator column in root type. Similar to option 2, and because LLBLGen Pro doesn't need a discriminator column for option 2, this type is supported but the discriminator column is ignored / not required.

The LLBLGen Pro designer can find inheritance hierarchies automatically.

All entity classes are based on lightweight custom classes, not on datasets or datatables.

The LLBLGen Pro designer allows you to map fields on entity fields of related entities, if that entity has one or more 1:1 or m:1 relations with another entity (or itself). This allows you for example to map 'CompanyName' in the Order entity to the related Customer's CompanyName field. In a databinding scenario, you'll then be able to view the company name of the Customer of the listed order without problems.

All database types made available by the databases currently supported are usable with LLBLGen Pro. An exception are the user defined types in Oracle and DB2, due to a restriction in ADO.NET.

Per project, you can specify abbreviations to full word sets, so names constructed for entities, entity fields, typedviews, typed view fields, stored procedure calls and stored procedure call parameters will now take into account any abbreviation - full word pairs specified. This greatly eases creating correct names from database schemas which have a lot of abbreviations used in field/table names.

LLBLGen Pro supports powerful .NET type conversion capabilities. Using type converters, you can map a field using any .NET type onto any database type. The conversion of data is done behind the scenes, transparently. For example, you can map an entity field with type XmlDocument onto a varchar field in the database, by applying a TypeConverter to the field which converts a string to an XmlDocument object and back. LLBLGen Pro ships with one type converter, to convert a numeric value to a boolean value and back. You can use this to develop true database independent code, which uses boolean entity fields with Oracle, SqlServer and other databases, even if that database (like Oracle) doesn't support a boolean type. The LLBLGen Pro SDK has a tutorial and sourcecode how to develop your own TypeConverters.

LLBLGen Pro migrates unique constraints to methods for fetching data using these constraints and migrates all found foreign key constraints to relations between entities (1:1, 1:n, m:n, m:1), fully automatically. It can find any m:n relation available in your database model, even relations you haven't thought of. All relations are available to you in code through methods which let you traverse relations or, for example, filter on objects using related objects. The generated code (SelfServicing and Adapter) supports full synchronizing of related fields and object relations. For example:

// C#. myOrder and myCustomer are fetched entity objects (Northwind)
myOrder.Customer = myCustomer;

will set myOrder.CustomerID to myCustomer.CustomerID and will place myOrder into myCustomer.Orders, the collection of Order entities related to myCustomer. If myCustomer is a new entity and CustomerID is an autonumber field, myOrder.CustomerID will be synchronized to the new value of myCustomerID after myCustomer is saved.

Entity object hierarchies can be saved as XML (even with cyclic references) and be fully re-instantiated from XML. LLBLGen Pro supports both compact XML (without type information) and verbose XML (with type information) and various other options to control the XML serialization.

Entity object hierarchies and single objects can be returned from and passed to an XML webservice or WCF service, all XML production/consumption is being taken care of by the LLBLGen Pro runtime code. Please read the documentation for more details on this feature.

All objects are serializable, which means they can be used in any remoting scenario.
You can use normal serialization based on the .NET BinaryFormatter logic or LLBLGen Pro's own, super fast and compact serialization logic.

Each database type is targeted using a custom driver, so that LLBLGen Pro can work with each database without knowing details about that database.

Full support for 1:1, 1:n, m:1 and m:n relations. All relations are auto-detected. You can add your own in the designer, hide auto-detected relations you don't need.

Full support for primary keys, foreign key constraints, unique constraints, defaults, autonumber fields, GUID fields, sequences, synonyms, views, stored procedures, database functions, relations with self, multi-field primary keys, multi-field foreign keys, multi-field unique constraints, objectified m:n relations, REF CURSORS in stored procedures, multiple resultsets in stored procedures and much more.

LLBLGen Pro contains advanced logic which can interpret any change in your schema and modify your project accordingly. You then re-generate your code and your schema change is available to you in the generated code. Refreshing a project to adapt the schema changes, keeps track of names already defined for fields, entities and relations so refreshing a project won't break any code targeting the generated code.

You can persist/fetch objects to / from multiple databases / schema's / servers in a single application, using a single set of entity classes. You can even switch between databases per call (using the Adapter paradigm).

You can add more than one catalog to an LLBLGen Pro project, and create relations between the entities of the different catalogs. The generated code then lets you work with the catalogs as if they form one catalog.

You can add more than one schema to an LLBLGen Pro project if you work with Oracle. This then allows you to add relations between the entities from these schemas and use the various schemas as one schema. SqlServer and DB2 also support multiple schemas per project: all schemas of a catalog in a project are retrieved and used.

'Transparent persistence' with SelfServicing template set
'Persistence as a service' with Adapter template set.

Supports Typed Lists, which are read-only lists created using entity fields from entities which are related. This way you can construct fast-loading read-only lists with related data (for example a subset of the order fields plus a subset of order's customer fields) which are fetched in 1 call. Typed Lists can be filtered and sorted using the same query objects as you use with entities. Typed Lists are generated as typed DataTables and are fully typed.

A database view can be added to your project which will result in a Typed DataTable with the view's columns, fully filterable and sortable using the same query objects as you're using with Typed Lists or entities. You can add a typed view mapped on a view even when you also have an entity mapped on that same view.

The generated code is fully object graph aware, which makes it a breeze to persist changes to the database. If you have changed a lot of entities in an object graph (e.g. a couple of customer objects, which contain a couple of order entities and these contain a couple of order lines for example), it doesn't matter which entity you save first, the generated code figures out which entities to save first and which to save last so no foreign key constraints are violated. Furthermore, it synchronizes FK fields with PK fields automatically, performs validation prior to saving an entity based on the validation rules you define, so to persist a graph is just one line of code and LLBLGen Pro takes care of the rest.

Only 'dirty' entities are persisted to the database, and only the fields changed are updated/inserted. The generated code will persist all included / referenced 'dirty' (changed) entities, even if the references are leading upwards in a parent-child hierarchy.

All objects are disconnected from the database and from any other object. You can use the entity objects, typed list objects and typed view objects without having a connection to the database; no database connection is kept open after you've fetched an entity unless you want it to.

Full paging support is available in entity collections and typed lists / typed views. Paging is performed on the database server, using a construct that fits best for the particular database system. Paging is available for any form of table and primary key type (1 field, multi field, sequenced, non-sequenced). Paging fetches only those objects matching the page, using a modified query in the database server.

LLBLGen Pro allows you to define EntityView objects on any entity collection which allows you to sort and filter the data in the entity collection per view, using the strongly typed predicate and sortclause objects you also use for database targeting filters.

Data in EntityViews as well as resultsets fetched from the database through a stored procedure or through a dynamically constructed list can be projected onto a datatable, entity collection or list of custom classes using standard generic code shipped with LLBLGen Pro. This allows you to create new sets of data from existing sets of data in-memory with very little effort. It also allows you to for example fetch entities through a stored procedure.

It's possible to perform a hierarchical projection of a full entity graph, using an entity collection as a startpoint. The projection can be onto a dataset (which will get one datatable per entity type, including datarelations) or a dictionary/hashtable with per type an entitycollection with the projection results per entity type found in the graph.

LLBLGen Pro allows you to fetch a stored procedure as an open datareader with 1 line of code. Furthermore it allows you to formulate a resultset from entity meta-data and fetch it as a datareader.

Uniquing Context support, which provides a unique object per loaded entity, so entity data which is fetched multiple times with the same context will result in the same entity object. You can have as much Context objects as you want, creating your own semantic context boundaries.

'Inject' instances of types at runtime into for example entity objects. This mechanism makes writing validation classes, concurrency predicate factories, authorizers etc. much easier as you don't have to add the code to inject instances of these classes into entity objects at runtime.

You can define, using whatever authorization mechanism you want to use, if a user at runtime is allowed to perform an action on / with an entity object or set of entity objects: field get/set, entity load, entity save (insert), entity save (update), entity delete, updates of entities directly in the database and deletes of entities directly in the database.

Define auditors which record audit information during the entity's life cycle and provide audit entity objects (of the type you provide) to the framework to be persisted automatically when the audited entity is part of a transaction with the database. This gives great flexibility what to audit and when and frees the developer from the hassle to persist the audit entities at some point in time.

LLBLGen Pro comes with a feature-rich validation framework, which makes it very easy to add validation code to the generated classes and intercept actions on the entities in a lot of stages and states.

Singularization and Pluralization of entity names and field name construction for relations is possible by using new plug-ins, which are bound to the new Designer events for singular to plural conversion and plural to singular conversion. The binding of these plug-ins to the events can be done using a dialog in the designer, so users are flexible to add own conversion plug-ins for LLBLGen Pro for their own language.

When doing an entity fetch, it's possible to exclude fields or to specify the subset of fields to fetch for an entity, a set of entities or a prefetch path node. This offers the ability to for example not load a large data field for an entity or set of entities to speed up performance. You can then load the data for the excluded fields later on into the same entity objects using specialized methods on (SelfServicing) the entity or entity collection or (Adapter) the DataAccessAdapter classes. This also gives the ability to specify that, for example, only field A, B and C should be fetched for entity E.

Both Adapter and SelfServicing support the UnitOfWork pattern using a UnitOfWork class. The UnitOfWork class lets you collect work to be done during a routine or sequence of routines (save, delete actions for entities or collections) and commit the work in a new or existing transaction in a single call. You can combine the unit of work classes with the multi-versioning feature every entity supports: you can save the values of the fields of an entity under a name inside the entity (and which will cross remoting boundaries and XML serialization actions) and roll back the values of the fields of that entity to a previously saved state later on. The UnitOfWork classes also support the addition of calls to routines via delegates or to pre-defined persistence routines, which makes it a very flexible form of collecting work which should be performed at commit time.

The template set SelfServicing contains advanced lazy loading (load on demand) functionality: it loads data on demand and you can overrule this feature at runtime at any given moment. This offers you the flexibility to always refetch data or to refetch data once or at intervals.

Both SelfServicing and Adapter support Prefetch Paths, a technology which lets you define per call which related entities have to be 'fetched' (loaded into memory) together with the entity or entities you want to load. This is done with one query per related entity type, so if you for example want to load a set of Customer entities and for each Customer in that set all Order entities and all Order Detail entities, you can define a prefetch path which loads all requested data with three queries: one for the Customers, one for the orders and one for the Order Details.

The results are then merged by the runtime library code. LLBLGen Pro's Prefetch Paths are more advanced than most competitor's equivalents because Prefetch Paths can contain filters, sort clauses and for example limits on the number of objects to return. This allows you to use Prefetch Paths in scenario's in which you for example want to load a set of Customers and their last Order entity, which with LLBLGen Pro's prefetch path technology will result in just 2 queries, no matter how many Customers are fetched. You can use prefetch path technology together with server side paging as well. In inheritance scenarios, you can use polymorphic prefetch paths to only fetch related data into given subtypes.

LLBLGen Pro supports delete and update statements which can be executed without first loading the data into memory. For example if you want to update a field of a lot of entities which match a given filter, you can execute that update statement directly on the database, using compile-time checked constructs using normal LLBLGen Pro elements, like entity fields and expressions.

ORMQueryExecutionException contains a dictionary/hashtable with all the database specific exception information contained by the wrapped database specific exception. This gives a generic way to obtain error codes and other information which is database specific. This avoids having to construct complex catch clauses because not all database providers inherit their exception class from DbException (.NET 2.0+). For saves and deletes, ORMQueryExecutionException also contains the entity involved which caused the exception. This helps recovering from an exception more easily in multi-entity save / delete actions.

The runtime libraries have a fine-grained tracing framework implemented which allows you to switch on parts of this framework to retrieve live information, like which SQL queries are produced, which code-paths are followed, which entities are passed to which routines etc. etc., even after deployment in production. This is ideal both for during development when you want to know which queries are generated by a routine, or for troubleshooting when an application in production doesn't behave as planned. The framework uses normal .NET tracing logic so you can easily pipe the tracing information retrieved to your own datastores using a trace listener, one from the .NET library, or one you write your own or third party.

Full support for ADO.NET transactions and ADO.NET SavePoints for transactions, which makes it easier to perform nested transactions within a single ADO.NET transaction. Adapter and SelfServicing also support COM+ transactions. Adapter's COM+ functionality also allows you to implement a simple wrapper class which supports additionally COM+ functionality like JIT (JustInTime activation), object pooling and much more. On .NET 2.0+ and in combination of SqlServer 2005, System.Transactions' functionality is also supported.

This provider allows you to fully use Linq in C# or VB.NET on .NET 3.5 to query your database, using Adapter or SelfServicing. We've spend a lot of time to implement as much Linq functionality as possible and have added extra extension methods to use all the LLBLGen Pro features through Linq constructs, like prefetch paths and exclude/include fields.

All generated code uses various well-known patterns to form a working layer and to deliver its functionality. It specializes the generic code in the runtime libraries using the Strategy pattern, it uses the Factory pattern, Data Access Object pattern and Data Transfer pattern.

Using scoped user code regions in the generated code, a developer can add own code to the generated code which is preserved when the code is re-generated. The generated code has various different user code regions for different purposes and developers can add their own by altering the templates. .NET 2.0/3.0/3.5 code is fully partial classes aware.

Generated code fully supports IBindingList, ITypedList, INotifyPropertyChanged and IEditableObject, which makes the generated code databinding aware out of the box and bound controls can offer more functionality (for example sorting in a grid) because of the implementation of IBindingList and IEditableObject.

Typed Lists, Typed Views and entity collections (both in Adapter and SelfServicing) are usable as a datasource in a design time databinding scenario in Visual Studio.NET: simply add them to the toolbox and drag them onto a form (webform or windows forms) and setup databinding behavior in a RAD way.

It's possible to add a relation object in code between any two entities without a lot of effort. It's also possible to add a relation between a derived table and an entity or between two derived tables.

LLBLGen Pro comes with two datasource controls: LLBLGenProDataSource (for selfservicing) and LLBLGenProDataSource2 (for Adapter) which allow you to setup two-way databinding in ASP.NET 2.0, both at design time and at runtime. The datasource controls of LLBLGen Pro are much more powerful than the .NET 2.0 datasource controls. Please consult the documentation for more details about these controls.

Code generated for VS.NET 2005 / 2008 is built with partial classes, which makes it easy to extend the generated code, through the partial class mechanism in .NET 2.0+.

These checks are performed automatically (unless you turn off automatic checking) to prevent overflows in the database. For example if you define a field of type decimal in your database, with precision 10 and scale 2, and you try to store a value 1234567.123 into this field, you'll get an exception that the value will cause an overflow as the precision/scale of the value exceed the precision and scale of the field. Due to these automatic checks, developers don't have to write validators for every numeric field to see if there is a possible overflow.

Generated code and the runtime libraries targeting .NET 2.0+ and CF.NET 2.0 utilize the new features of .NET 2.0+ like generics for generic, strongly typed entity collections and nullable types for value-typed entity / view fields.

• Table joins seen as object relations and formulated by adding relation objects to a collection
• Compile time checked filter construction, with easy to formulate constructs like (CustomerFields.CompanyName=="SolutionsDesign")
• Ansi joins and non-ansi joins supported
• Join hints can be specified for fine grained control over how joins should take place
• Support for weak (optional) and strong relations (1:1, 1:n, m:1)
• Predicate specification through construction of predicate objects. You can add your own predicate types.
• Custom filter support in JOIN clauses
• 100% typed dynamic filter construction using Predicate objects
• All constructions are database-generic, unless a database specific predicate class is used
• Support for sorting, group by, duplicate filtering and resultset limitations (number of rows returned)
• Full support for nested filter constructions
• Support for full text search on SqlServer
• Support for set based comparisons (sub-queries), expression based comparisons, having clauses in group by collections, like comparisons (case sensitive and case insensitive)
• Scalar query support for easy and efficient retrieval of values from the database
• SQL Expression and aggregate function support in all areas of the query mechanism for as much flexibility as possible when formulating complex queries.
• Join an entity multiple times using aliases for advanced queries spanning multiple times the same entity.
• Polymorphic queries in inheritance scenarios
• Entity type filters in inheritance scenarios
• ScalarQueryExpression support for embedding scalar queries in select lists
• Database function call support, which allows you to call any database function inside an expression.
• CASE support for fine-grained select list tweaking.

Full support for Group By and Having constructs using typed objects and collections. Full support for all known aggregate functions like Count(field), Count(*), Sum, Avg, StDev, Max, Min etc. You can create dynamic lists with a few lines of code which can embed data which is produced by a group by query using aggregate functions, created completely using typed objects and no SQL programming nor stored procedures usage.

LLBLGen Pro supports SQL Expressions so you can, for example in combination with aggregate functions, create very advanced filters or data retrieval queries, using SQL expressions on fields. For example filters like Sum(field1 * field2) > Sum(field3) are possible. Expressions are re-usable so you can create a library for expression producing methods and re-use expression objects in different filters or queries. Examples of expressions could be field arithmetic but also a combination of a database function call and arithmetic or a scalar query which is embedded as a subquery.

Scalar queries, if necessary using aggregate functions and expressions, filters (even multi-entity spanning filters) are fully supported. The Scalar queries let you easily retrieve values from the database without having to read large amounts of objects into memory. For example the COUNT(distinct field) for a given filter can be easily determined with a couple of lines of code.

The generated code offers functionality that makes it easy for you to control concurrency at a low level (save/delete) by specifying filters using predicate objects which are added to the query executed. This way you can control when to use which type of concurrency and how you implement it (timestamp, multi-field checks etc.). You can also specify your own concurrency control filter producer object which is consulted during recursive saves.

All queries are generated on the fly by highly tuned query generator engines, one per supported database. All queries are parameterized to fully utilize RDBMS optimizers. Dynamic SQL lets you formulate any filter set or sort clause in your C# or VB.NET code, without having to worry about stored procedures and low level tiers. No more SQL programming at all, no more stored procedures. Due to the typed, object oriented query mechanism, your code is database generic, and you can therefore re-use your code for multiple databases.

A new class has been added, DerivedTableDefinition, which is used to specify a complete query as a FROM clause. It's the final piece of the puzzle to create any SQL query though LLBLGen Pro's query api.

You can call any stored procedure in a friendly way (1 method call) using typed parameters and utilize the returned data in datasets/datatables. The interface to your stored procedures is database generic. You can also use the stored procedure call to retrieve a resultset as a datareader and project the resultset onto entities or your own custom classes, which offer you the ability to fetch entities using stored procedures.

Support for SqlServer (MSDE, SqlServer 7/2000/2005/Express, SqlCE 2.0, 3.0, 3.5), Sqlserver CE Desktop (New!), Oracle (Oracle 8i / 9i /10g), PostgreSql 7.4+/8.x, Firebird 1.x / 2.x, IBM DB2 UDB (7.x/8.x/9.x), MySql (4.x, 5.x), Sybase Adaptive Server Enterprise (ASE) (New!), Sybase SQL iAnywhere (ASA) (New!) and MS Access 2000/XP/2003/2007

Generated code supports .NET 2.0/3.0/3.5, CF.NET 1.0 and CF.NET 2.0 and generated Visual Studio.NET project files are compatible with Visual Studio.NET 2002/2003/2005/2008.

The LLBLGen Pro designer features a plug-in system which allows you to target the complete loaded project and manipulate every object in that project. A selection framework is available to allow users to pre-select targets to work on. The LLBLGen Pro SDK comes with the sourcecode for the plug-ins shipped with LLBLGen Pro and documentation how to write your own.

Customers have access to the SDK and full source code for the runtime libraries, template parser/interpreter, the C#/VB.NET template engine, all task performers, all plug-ins and all database drivers shipped with LLBLGen Pro. You can write your own task performers which have full access to the project in the GUI, write/extend templates, extend the template language/parser/interpreter, write your own plug-ins or extend the runtime libraries. You can also use the SDK to create command line tools. For customers several command line tools are available such as a command line code generator for batch processing code generation and a standalone LLBLGen Pro project viewer.

All functionality is supported in both C# and VB.NET.

Design your entities off-line and disconnected from the database server, and update your project with changed schema data within seconds when you are back on-line

LLBLGen Pro comes with an in-depth manual, a full reference manual and full SDK documentation.

An SqlServer project can be used to generate code for the Compact Framework .NET v1.0 and v2.0. This way you can use LLBLGen Pro also to develop applications specifically for the Compact Framework.NET v1.0 and v2.0.