Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > General > General Chat> ADO.NET 3.0 Entity Data Model
 

Pages: 1 2
General Chat
ADO.NET 3.0 Entity Data Model
Page:2/2 

  Print all messages in this thread  
Poster Message
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37694 posts
# Posted on: 26-Sep-2007 10:46:23.  
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. Regular Smiley

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 Regular Smiley 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.
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
pat
User



Location:
CA, USA
Joined on:
02-Mar-2006 06:53:17
Posted:
215 posts
# Posted on: 26-Sep-2007 18:38:26.  
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. Regular Smiley

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


-----------------------------------------------
LLBLGen 5.1 - SQL 2016, C#, .NET 4.6
 
Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37694 posts
# Posted on: 28-Sep-2007 10:40:48.  
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. Regular Smiley

managing multiple related entities as a single unit.

Ok, so also 1:n related entities?

Quote:

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. Regular Smiley
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Pages: 1 2  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.