Hi,

when trying to extend the generated LLBLGen code in any way I often noticed that I am hindered by my limit understanding of the life cycle of entities, collections etc. There are a lot of comments and documentation but they describe more isolated functions and functionality. What I am missing is an overview of what happens on application startup, when entities, entity collections are instantiated, how the persistence process works etc.

Are there diagrams, description (which I might not have seen) etc. which explain the life cycle of an entity or on a bigger scale an LLBLGen application?

E.g. something like this (just made up) Startup - Setting up entity field properties (FieldInfoProvider.cs) - Mapping entity fields to database fields (PersistenceInfoProvider.cs) ...

SampleEntity e = new SampleEntity(); - Get factory ... - Factory instantiates fields via FieldInfo collection ....

Thanks a lot, Patrick

pat wrote:

Hi,

when trying to extend the generated LLBLGen code in any way I often noticed that I am hindered by my limit understanding of the life cycle of entities, collections etc. There are a lot of comments and documentation but they describe more isolated functions and functionality. What I am missing is an overview of what happens on application startup, when entities, entity collections are instantiated, how the persistence process works etc.

Are there diagrams, description (which I might not have seen) etc. which explain the life cycle of an entity or on a bigger scale an LLBLGen application?

E.g. something like this (just made up) Startup - Setting up entity field properties (FieldInfoProvider.cs) - Mapping entity fields to database fields (PersistenceInfoProvider.cs) ...

SampleEntity e = new SampleEntity(); - Get factory ... - Factory instantiates fields via FieldInfo collection ....

Thanks a lot, Patrick

THis isn't documented in public documentation other than the Entity lifecycle in Concepts -> O/R mapping.

The reason is that it's not necessary to know the exact steps what happens behind the scenes, as you should focus on: 1) what do I want to do? 2) what does the manual tell me where I should put my work what I want to do?

So do you have an example what you want to do which you found hard because you didn't know the right framework details? LLBLGen Pro generated code + runtime libs form a framework which means that you build on top of that and if required, fill in the gaps deliberately left open with your own details or extend / replace parts of the framework. In general it's not really handy to replace core framework elements because that will likely make the framework fall apart (if it's possible even).

It's likely what you want to achieve is possible without replacing framework elements. Could you give an example of that?

Otis wrote:

The reason is that it's not necessary to know the exact steps what happens behind the scenes, as you should focus on: 1) what do I want to do? 2) what does the manual tell me where I should put my work what I want to do?

Hi Frans,

ok here are some of the challenges I have with implementing LLBLGen and where a deeper understanding of the life cycle would maybe help me understand if and how I could extend the framework:

• Supporting dynamic fields There is a method of doing it via a "MetaData" table which contains rows for the data of each meta data field. But the problem here is still how to implement data binding (so that the new columns show up in grids). As well how to make it part of an edit cycle if the user wants to undo his changes etc. Understanding entities and entity field creation might give me some helpful ideas.

• Support for fields from different data sources Sometimes a BO might need to contain data from sources other than a database. The new fields need to be loaded on creation, be part of the normal edit cycle of the entity and just get persisted a different way when the object is saved...

• Supporting caching If two different routines which don't know anything about each other fetch the same entity (or collection) directly after each other it gets fetched twice (I know there is the context object but it doesn't cover cases like cache timeout etc.). Understanding for example how the DataAccessAdapter works might give me hints on how to add support for transparent caching. etc....

Thanks, Patrick

• Supporting dynamic fields

You might find the following discussion threads useful: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=8232 http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=11806

• Support for fields from different data sources

Please check the LLBLGen Pro manual for the following: 1- Generated code - Adding your own code to the generated classes 2- Using the generated code -> Tapping into actions on entities and collections In general these are a must read if you want to extend the framework

• Supporting caching

You should implement your caching routines, and you might use Contexts within.

Walaa wrote:

You might find the following discussion threads useful:

Thanks I participated in both threads. They both don't allow for dynamic fields at runtime due to the way LLBLGen caches the field properties (otherwise LLBLGen seems to be very capable of dynamic fields!). The only ways I know of doing it would be via an XML column or via "MetaData" table which contains rows for the data of each meta data field. Both of these options are still separate though of the normal entity edit cycle (when bound to e.g. a grid). So if the user edit's a few cells than presses ESC only the LLBLGen fields will revert to their original value the custom field's won't.

How would you please make custom fields become fully part of an entity for editing, field level versioning etc. ?

Walaa wrote:

Please check the LLBLGen Pro manual for the following: 1- Generated code - Adding your own code to the generated classes 2- Using the generated code -> Tapping into actions on entities and collections In general these are a must read if you want to extend the framework

Thanks I read them both. The example does mostly fit the way LLBLGen works but there is still the the issue about editing (see above).

Walaa wrote:

You should implement your caching routines, and you might use Contexts within.

The point of the thread was though to show reasons why it would be good for customers to be able to understand the entity life cycle... So even though I would have to implement caching myself understanding more about the inner working of LLBLGen would be helpful.

Thanks, Patrick

pat wrote:

Walaa wrote:

You might find the following discussion threads useful:

Thanks I participated in both threads. They both don't allow for dynamic fields at runtime due to the way LLBLGen caches the field properties (otherwise LLBLGen seems to be very capable of dynamic fields!). The only ways I know of doing it would be via an XML column or via "MetaData" table which contains rows for the data of each meta data field. Both of these options are still separate though of the normal entity edit cycle (when bound to e.g. a grid). So if the user edit's a few cells than presses ESC only the LLBLGen fields will revert to their original value the custom field's won't.

How would you please make custom fields become fully part of an entity for editing, field level versioning etc. ?

that's explained in the threads linked (second thread actually, by smartwebagent ). It's hard to do, because you have to deal with 1:n related property column entities. In other ways, it's not supported. C# is a statically typed language, you can't add typed elements to the classes based on data in a table, that's not supported.

The point of the thread was though to show reasons why it would be good for customers to be able to understand the entity life cycle... So even though I would have to implement caching myself understanding more about the inner working of LLBLGen would be helpful.

We won't publicly document every element inside the framework, similar why MS doesn't do that with .net. That's why I asked you why you want to extend it, so we can point you to the elements of interest for you. Dynamic properties aren't really supported, so I hope that's clear now.

The thing about caching is that it has no real value: people often think that caching can help them get more performance but that's a myth: caching actually costs MORE performance. In one occasion it can give better performance: if you fetch single entities only. It can then do a pk check in the cache and fetch the object from there. But even then you'll run the risk of working with outdated data, plus if you have multiple threads working on the DB, you WILL use stale data. That is only OK if it's static data, i.e. data which won't change, i.e. lookups. See my article about caching in o/r mappers