LLBLGen Pro Runtime Framework features.

Below you'll find an overview of the main features offered by the LLBLGen Pro runtime framework. This list should give you an indication what you can expect from the runtime framework and the generated code. There are many, often smaller, features not listed below, however these are explained elsewhere in this documentation.

Where applicable, links to detailed information is added. The features are categorized for easy navigation. Items marked with New! are new in v5.x.

Categories:

Entity management & usage

  • 'Transparent persistence' with SelfServicing template set and 'Persistence as a service' with Adapter template set. Two paradigms are supported, which both have their own characteristics and specific features. More information...
  • Graph-aware save logic The runtime will persist changed entity instances in the right order and will automatically traverse an entity object graph in-memory to obtain all work to be done.
  • Entity View support Define different views (based on sort clauses and/or filters) on an entity collection in-memory and bind those views to UI controls. More information: Adapter, SelfServicing
  • Dependency injection mechanism The runtime framework has its own IoC/Dependency Injection mechanism to make it transparent and flexible when validators, concurrency predicate factories, auditors and authorizers are injected in entity instances. It makes working with validators and the like easier as you only have to define in which instances a validator has to be injected without writing code to do so. More information...
  • Authorization support The runtime framework has fine-grained authorization supported through authorizers you can write yourself using easy to extend base classes. Authorization can be used for example to avoid having some users see some data or do certain actions to entity instances. More information...
  • Auditing support The runtime framework has transparent and in-transaction auditing support for tracking and logging actions taken on entities. Audit information can be exported to any output you like or transparently be saved as entities inside the same transaction. More information...
  • Validation support The runtime framework supports deep, fine-grained validation support through validator objects you write using simple extendable base classes. More information...
  • Unit of Work support You can group multiple database actions you want to take on various entities, like delete and insert/update, into a Unit of Work object which you then can use to execute all work inside that Unit of Work as a single transaction. More information: Adapter, SelfServicing.
  • Hierarchical in-memory projections of entity collections The runtime framework allows you to create projections of the full graph of all the entities inside a given entity collection onto a DataSet or a Dictionary object. More information: Adapter, SelfServicing
  • Allowed Action Combinations support. New! Specify which actions are allowed on an entity instance: Any combination of Create/Read/Update/Delete. Action Combinations make it easy to define e.g. entities which can only be created or read but never updated nor deleted. The action combinations are defined at the mapping level and checked inside the runtime and are additional to the authorization framework. More information...
  • Design typed projections over a set of related entities using Typed Lists Typed Lists are generated as typed datatables, and are usable as flat, read-only data sets obtained from the data of one or more related entities using a query designed in the designer. More information: Adapter, SelfServicing.
  • Entity instance uniquing ('Identity map') through Context objects. To be able to obtain the same class instance for when the same data (entity instance) is fetched twice, you can use Context objects which allow you to have unique entity objects locally within scopes. More information: Adapter, SelfServicing
  • DataScopes DataScopes define a 'scope' in which data is controlled and which takes away a lot of manual work regarding managing in-memory data in desktop applications, including creation of ready-to-use Unit of Work objects with cascading deletes/updates. More information...
  • Multi-versioning of entity fields The values of an entity inside an entity object can be versioned so you can roll back to a previous version of a field value. More information: Adapter, SelfServicing
  • Multi-tenancy support The LLBLGen Pro runtime framework offers multi-tenancy support at the catalog and / or schema level through catalog / schema name overwriting (per call, or statically defined through a config file). More information...
  • Advanced lazy loading/load on demand. Lazy loading / load on demand, available in SelfServicing, lets you load related entity data automatically when a navigator property is read. You can control whether this happens every time or just once
  • Built-in value validation for string/array length and precision/scale ranges The runtime framework automatically validates values if they cause an overflow with respect to maximum string/array lengths or with respect to precision/scale for decimal typed fields. Validation is based on field aspects defined in the entity model. More information...
  • Persistence of 'dirty' (changed) data only Update and Insert queries only affect the fields which are changed ('dirty')
  • Flexible concurrency control mechanism The runtime framework comes with a flexible, IoC/Dependency Injection friendly mechanism which allows you to formulate your own concurrency system, so you don't have a pre-fab solution which might not fit your needs. More Information: Adapter, SelfServicing
  • Full WCF Data Services support Expose your LLBLGen Pro runtime framework powered domain layer through a WCF Data Services service using the WCF Data Services tools in VS.NET. More information...
  • Full XML serialization support Entity graphs in-memory, unit of works and low-level query API elements are serializable and deserializable to/from XML in a couple of different XML formats and contain change tracking information. More information...
  • Full XML Webservice / WCF support Entity graphs can be used with WCF services/Web services and change tracking information is included in the XML, using efficient XML formats. More information...
  • Full binary serialization support State-of-the-art binary serialization support with own binary serialization pipeline for extremely fast serialization and de-serialization as well as advanced data compacting for keeping serialized data small. More information...
  • Full Linq support with our own Linq to LLBLGen Pro provider A full Linq provider is included in the LLBLGen Pro runtime framework which allows you to use Linq queries to query your domain. Our linq provider is built on top of our lower level querying API and you can use Linq queries side by side with the lower level API queries and QuerySpec queries. The Linq provider is extensible using flexible FunctionMapping definitions to map your own .NET methods onto SQL constructs to be used in a Linq query. More information...
  • Full Async API. The runtime framework offers a full async API to be used with the .NET 4.5 async/await keywords in C# and VB.NET. The Async API is usable in Linq, QuerySpec and the low-level API for both fetching of data and entity persistence. More information...
  • Transparent Transient Error Recovery. New! The runtime framework offers the ability to recover from transient errors occuring during database activity. Especially useful on Azure where database connections can be less reliable.
  • Plain SQL API. New! You can execute plain SQL statements using parameters directly onto the database, including fetching resultsets and projecting the resultsets to POCO classes. With this API you don't need a microORM on the side anymore for those situations where the runtime couldn't give you the right query. This API is also very fast, outperforming most microORMs. More information: Plain SQL API.
  • Server-side paging support All select / fetch queries support server-side paging or when server-side paging isn't possible it will switch to client-side paging to perform the required action on the client using DataReader based paging (read as much rows as required after which the DataReader is closed). Server-side paging is done using efficient paging queries, tailored for the RDBMS at hand, utilizing native paging mechanisms if available. More information: Adapter, SelfServicing
  • Table Valued Function Support. Any Linq / QuerySpec query can use a Table Valued Function instead of a normal entity as the source for data. Linq, QuerySpec
  • Extensible Query Resultset Caching. Any resultset fetched from the database can be cached for a given amount of time for a given query, so any subsequential execution of the exact same query / parameter values combination will not hit the database again but re-use the values cached. More information...
  • Temporal (History) Table support. New! For SQL Server 2016 and higher/ DB2, temporal tables are supported through Linq / QuerySpec (Select / fetch queries only). Temporal tables are an easy, friction free way to store previous versions of modified / deleted rows in a table. The temporal table support in LLBLGen Pro allows you to include older versions of entities when querying. More information: Linq, QuerySpec
  • Hints support. New! For SQL Server / MySQL, select target hints are supported through Linq and QuerySpec. More information: Linq, QuerySpec
  • Fetch a resultset as a datareader Any query, be it for fetching entities, a stored procedure call or a custom projection, is obtainable through a datareader, so you can handle the query processing directly 'on the metal' if you like. More information: Adapter, SelfServicing
  • Exclude fields from entity fetches If you want to exclude one or more fields from an entity when fetching it (or when fetching a collection of these entities), for example because they contain large data and you don't need it at that point, you can do so by specifying them in the query. Later on, you can fetch them in an additional, efficient batch query if you need the data. More information: Adapter, SelfServicing
  • Advanced Prefetch functionalty of related entities/eager loading. The runtime framework allows efficient loading of entity graphs using 'prefetch paths', which define which related entities should be loaded using which filters. More information: Adapter, SelfServicing
  • Ability to execute delete/update statements directly on the database The runtime framework allows update and delete queries to be executed directly onto the database for fast bulk operations using single statements. Queries can be created using typed, entity based query objects. More information: Adapter, SelfServicing
  • Dynamic relationship/join support Normally, you'd use the relationships defined in the entity model, but if you need to join two entities in a query which don't have a pre-defined relationship in the model, you can.

  • Fully object oriented, typed query and sorting APIs   The runtime framework comes with two query APIs: QuerySpec and the lower-level API. Both provide a rich, compile-time checked querying system which has the following highlights:

    • Table joins seen as object relationships and formulated by adding relationship objects to a collection
    • Compile time checked filter construction, with easy to formulate constructs like (CustomerFields.CompanyName=="Solutions Design")
    • Ansi joins and non-ansi joins supported
    • FULL, LEFT, INNER, CROSS and RIGHT JOIN joins supported.
    • Join hints can be specified for fine grained control over how joins should take place
    • Support for 1:1, 1:n, m:1 relationships, ad-hoc (dynamic) or pre-defined in the model.
    • Predicate specification through construction of predicate objects. You can add your own predicate types.
    • Custom filter support in JOIN clauses for complex ON clauses
    • All constructions are database-generic, unless a database specific predicate class is used
    • Support for sorting, group by, duplicate filtering (DISTINCT) and resultset limitations (number of rows returned), which automatically switches to efficient, datareader based, client-side distinct/row filtering if these constructs can't be emitted into the SQL query due to violating types/sort clauses which otherwise would cause an error
    • Support for nested filter constructions
    • Support for full text search on SQL Server
    • 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
    • Database function call support, which allows you to call any database function inside an expression.
    • CASE support for fine-grained select list tweaking.
    • Derived table support for joins with queries.

    More information: Low-level API, QuerySpec API

  • Support for Group By, Having and Aggregate functions You can formulate complex group by queries, including having clauses and use all aggregate functions supported by the supported databases. More information: Adapter, SelfServicing
  • Advanced SQL Expressions Formulate complex expressions using entity fields defined in your model and use them in query projections, filters, scalar queries, inserts and updates. More information...
  • Scalar query support Using the query mechanism, formulate compile-time checked scalar queries and use them in projections or filters, or fetch a single scalar value, based on - for example - an aggregate function or expression. More information...
  • Derived table support If you need to join with the resultset of a query, or want to use a projection on top of a resultset, you can do so with the runtime framework's support for derived tables. More information...
  • Powerful projection framework The runtime framework supports the creation of custom projections of a query created from one or more related entities and can project the resultset to any type or an untyped object like a datatable. The projection system is extensible and easily adjusted with custom projectors for your own needs. More information: Adapter, SelfServicing
  • Extensible generated code The generated code is extensible (to for example override virtual methods to extend /tap into the runtime framework) through partial classes or through user code regions which contents are preserved across code generation cycles. More information...
  • Full implementation of IBindingList, ITypedList, INotifyPropertyChanged and IEditableObject. The generated code is ready to be used with MS' databinding functionality in the different UI frameworks.
  • Full support for design time databinding Design time databinding in Winforms, WPF and ASP.NET.

General

  • Typed Views mapped onto table, view, stored procedure resultset or table-valued function resultset A Typed View mapped onto a view, table, stored procedure resultset or table-valued function resultset is either a POCO class with a query or a typed datatable which can be used for read-only data access using an easy-to-use querying system. More information: Adapter, SelfServicing
  • True database independent code with Type Converters. You can map a field of any .NET type to any table/view field of any .NET type using TypeConverters which convert the values back/forth transparently behind the scenes. LLBLGen Pro Runtime Framework comes with the following built-in system type converters (so no additional type converter is needed)
    • Boolean <-> Numeric
    • Boolean <-> Char (Y/N)
    • Int16 <-> Decimal
    • Int32 <-> Decimal
    • Int64 <-> Decimal
    • Byte <-> Decimal
    • Single <-> Decimal
    • Double <-> Decimal
    • Guid <-> String (char32)
    • Guid <-> byte[]
    • DateTime (local timezone) <-> DateTime (UTC)
    • Char <-> String(1)
  • Native Enum support  Entity fields can have an Enum type as their type without special type converters, and this can be used in inserts/updates/deletes and selects and also filters
  • Native Spatial types / CLR UDT types support (SQL Server specific) Saving / loading of entities with spatial or CLR UDT typed fields are fully supported. Saving / loading of these entities works the same way as with entities with normal CLR typed fields.
  • Flexible, DbProviderFactory based query engines All query engines are DbProviderFactory based and aren't tied to a specific version of the used ADO.NET provider.
  • Fine-grained tracing framework The runtime framework offers fine-grained tracing of actions taken on the entity objects, which queries / SQL is generated and executed, which actions were taken during persistence operations and much more. This gives a deep insight in what's going on behind the scenes of the runtime framework and makes it easier to fix problems. More information...
  • Support for ADO.NET transactions, ADO.NET Transaction save-points and System.Transactions The runtime framework offers wide support for all transaction mechanisms you want to use, be it native ADO.NET transactions or for example System.Transactions based transactions. Savepoints, for in-transaction rollbacks to save points within the transaction are also supported on the databases which support these actions. More information: Adapter, SelfServicing
  • Full ASP.NET two-way databinding support using our own datasource control. The runtime framework comes with a datasource control (one for Adapter and one for SelfServicing) which offers rich, two-way databinding support for ASP.NET based technologies like ASP.NET webforms. More information: Adapter, SelfServicing
  • Partial classes support All generated code is partial classes aware and easily extended.
  • Support for direct calls to stored procedures Call an action stored procedure (which doesn't return a resultset) or a retrieval stored procedure (which does return one or more resultsets) using generic simple code, like it's a normal method in your .NET code. You can also add stored procedure calls to the Unit of Work objects, or grab the call as a query and use it as a source for a projection. More information: Adapter, SelfServicing