Currently, my database has a few tables which I want to represent in code not just as a single entity with all simple type properties (int, string, DateTime, etc.), but rather a single entity containing a mix of simple type and complex type properties. For instance, I have an Order table which has 10 fields I'd like to encapsulate in a BillTo entity (OrderEntity.BillTo), another 10 fields to encapsulate in a ShipTo entity (OrderEntity.ShipTo), 6 to encapsulate in a CreditCard entity (OrderEntity.CreditCard), and the remaining 20 or so would be simple properties of the Order entity.

Is it correct that LLBLGen doesn't support this type of configuration? I really want to avoid writing custom classes which merely convert an LLBLGen entity into my own custom entity. I'd rather pass around the LLBLGen entity and collection objects and avoid the unnecessary effort.

If this is not allowed in LLBLGen, are there any recommendations other than the custom class approach to handling this scenario? The obvious one is to change the db schema to add additional tables which represent the 'child' entities, move the necessary data from Order into the other tables and have a FK back to Order, but that level of change might not be possible in my environment.

lodestar wrote:

Currently, my database has a few tables which I want to represent in code not just as a single entity with all simple type properties (int, string, DateTime, etc.), but rather a single entity containing a mix of simple type and complex type properties. For instance, I have an Order table which has 10 fields I'd like to encapsulate in a BillTo entity (OrderEntity.BillTo), another 10 fields to encapsulate in a ShipTo entity (OrderEntity.ShipTo), 6 to encapsulate in a CreditCard entity (OrderEntity.CreditCard), and the remaining 20 or so would be simple properties of the Order entity.

Is it correct that LLBLGen doesn't support this type of configuration? I really want to avoid writing custom classes which merely convert an LLBLGen entity into my own custom entity. I'd rather pass around the LLBLGen entity and collection objects and avoid the unnecessary effort.

If this is not allowed in LLBLGen, are there any recommendations other than the custom class approach to handling this scenario? The obvious one is to change the db schema to add additional tables which represent the 'child' entities, move the necessary data from Order into the other tables and have a FK back to Order, but that level of change might not be possible in my environment.

I've just been reading about this in Applying Domain-Driven Design and Patterns as recommended by Fans: Embedded Value I think its called and supported by NHibernate

I'm struggling to see a good use/need for this: In your example above, it would seem to me that BillTo and ShipTo are addresses and therefore should be in their own Address table to which Order has two FK references. This would give you exactly what you want on the Order entity: ie myOrder.BillTo.Postcode or whatever and would allow reuse of Address for other entities.

Same for the credit card though their might be an M:N relationship - CreditCard storing the details (could then be related to the Customer as DefaultCreditCard or whatever) and an OrderCreditCard table linking a particular order to a particular credit card. An order view could be used to retrieve this back as a flat structure where required.

It may be that the database structure was inherited and/or not changeable but other than that where could this Embedded Value be used (not be critical or dismissive but genuinely looking for ideas!)

Cheers Simon

[quotenick="simmotech"]I've just been reading about this in Applying Domain-Driven Design and Patterns as recommended by Fans: Embedded Value I think its called and supported by NHibernate [quote]

The NHibernate mapping calls these components.

simmotech wrote:

I'm struggling to see a good use/need for this:

The main reason would be to reduce duplication. So, if you could reuse these objects in more than one class. It also makes your domain model more consistent. I think NHibernate will also lazy load components, so when you fetch customer you don't need to fetch Customer.Address fields unless you access them.

Also, I wonder if you can simulate this in LLBLGen by mapping two entities on the same table hidding the "other" fields, and relating them in the designer.

BOb

As you said a re-structure of the database is the best solution, but if this is not available. Then You may use LLBLGen Pro to map more than one entity to the same database Table. So you should map an entity "BillTo" to the same orders table, select the 10 fields that you want and select the Orders PK as well (we will use this field to manually create a relation to Orders table). And so for the other entities. Then again by using the LLBLGen Pro Designer you might manually define relations from your newly created entities to the OrderEntity.

Must be an echo in here...

BOb

Must be an echo in here...

I didn't read your last line.