pat wrote:

Otis wrote:

The core purpose of these entities is that you can treat a group of entity types as a single unit, like 'sales order' which has a reference to 'customer', order, order items and for example the employee who logged the order. I don't see them play a large part in extensive fetch scenario's, like lists of data, as it's more efficient to use dyn. lists or typed lists for that. However for managing data they can be helpful, also because you can add validation for a single unit so validation and BL rules are simpler.

Hi Frans,

this is **exactly **what I am looking for and what I am missing in LLBLGen at the moment. It's very similar to what CSLA.NET proposes. Unfortunately It seems like you didn't implement the idea yet (as of LLBLGen 2.5).

Are there any plans to implement it in the next release? If not do you have any thoughts on how I could simulate it for now?

Thanks, Patrick

There are a few problems with these: the main thing is that they have rules, so if your model doesn't fit the rules, you're not having a great time For example, if you map such an entity on multiple tables and the PK of the second table for example isn't in the entity, you can't save a new one.

Therefore, the field has to be part of the entity, which is perhaps not what you want.

This is something else than value objects like Address which is mapped on 3 fields in customer and which is a related object in customer.

For v3 we'll reconsider implementing this.

Otis wrote:

For example, if you map such an entity on multiple tables and the PK of the second table for example isn't in the entity, you can't save a new one. Therefore, the field has to be part of the entity, which is perhaps not what you want.

Maybe there was a misunderstanding? I meant this:

Otis wrote:

The core purpose of these entities is that you can treat a group of entity types as a single unit, like 'sales order' which has a reference to 'customer', order, order items and for example the employee who logged the order. ....for managing data they can be helpful, also because you can add validation for a single unit so validation and BL rules are simpler.

managing multiple related entities as a single unit.

The main things it would solve for me would be: - not having to load the customer object just because I need the customer name to appear in the order entity but rather get the customer name with an inner join - validation, business rules etc. based around the use case of the order

Would there be a way to simulate this with the current or next versions v2.6 of LLBLGen?

Thank you, Patrick

pat wrote:

Otis wrote:

For example, if you map such an entity on multiple tables and the PK of the second table for example isn't in the entity, you can't save a new one. Therefore, the field has to be part of the entity, which is perhaps not what you want.

Maybe there was a misunderstanding? I meant this:

Otis wrote:

The core purpose of these entities is that you can treat a group of entity types as a single unit, like 'sales order' which has a reference to 'customer', order, order items and for example the employee who logged the order. ....for managing data they can be helpful, also because you can add validation for a single unit so validation and BL rules are simpler.

managing multiple related entities as a single unit.

Ok, so also 1:n related entities?

The main things it would solve for me would be: - not having to load the customer object just because I need the customer name to appear in the order entity but rather get the customer name with an inner join - validation, business rules etc. based around the use case of the order

Would there be a way to simulate this with the current or next versions v2.6 of LLBLGen? Thank you, Patrick

If you're after typedlist-like entities which are updateable, there are some things which will have to be taken into account: the FK/PK fields of the entities involved have to be filled, which can be a limitation.

If you want related data of a related entity without loading it, that's a thing you've to live with. You can exclude fields to fetch though in v2.5: so if you need the customer entity's companyname, you can exclude all other fields (the pk is included anyway) and then fetch the entity, which means the customer entities have just their pk and the companyname filled.