I consider using LLBLGen Pro with new project in our company. After reading documentation I decided to use Adapter scenario to generate DAL tier for my application. Maybe I missunderstand something but I can't figure out when should I fetch related entities. For Example:

I have a Customer entity (CustomerEntity class and CustomerManager class). Each customer has orders and invoices (i have more relations but for simplicity let's assume there are only two). What should I fetch when CustomerManager->GetCustomer method is invoked?

• Only Customer Entity

This could be confusing for CustomerManager's users. They have to remember to invoke another method to get customer's invoices and orders (for instance CustomerManager->GetCustomerOrders). In my opinion this isn't a good solution. PL tier developer can forget (and if it's possible it will probably happen ) about this rule and simply access CustomerEntity->Orders property. I think in this case making CustomerEntity->Orders (and other relations's fields of course) private would be the best way out.

• Customer Entity with related orders and invoices (using Prefetch Paths)

I think that this solution could significantly decrease performance of my application (each customer may have thousand of orders and invoices).

Which way should I choose? Maybe somebody knows better than I showed above.... Any help would be appreciated.

It all depends on you and on your application requirements. How and where are you going to display your data, and in which way? For example do you need to fetch all the 1000s orders related to a customer, or you can use paging stuff.

Also remeber that you can use TypedLists, TypedViews and Dynamic Lists, to get read-only data. Which are very handy in many situations.

Thank you for your explanation. I see I have to read more about typed view, lists and dynamic lists in documentation. But this is not exactly what i expected . At this moment I try to find the best way of fetching related entities (even when entity has only 1:1 relations). Let's forget for a moment about processing thousands of entities - my question is rather about operating on single entity (for example Customer). How should I implement fetching entities related to Customer? Should I fetch all entities at once in GetCustomer method or create separate methods to fetch related entities.

How do you do it in your projects?

At any given moment in your application, you should fetch the data you need to use in the application and thus also get rid of the data you don't need anymore. If your application needs to process 10 entities related to customer, it's thus necessary to fetch those 10 entities when you're going to process them, not 15 or 1000, but the 10 you need.

Prefetch paths make fetching related entities more efficient as you can have 1 query per graph node so 10 customers which each 10 orders will still give 2 queries, not 11. The prefetch paths offer you to specify additional filters, so you can prefetch just 2 related orders per customer for example, or just the orders matching a filter.

So it's hard to say "do this and you're set", it really depends on the situation at hand: at one time you'll need all the data up front, at another time you just need one entity at a time, and fetch a new one when you're done.

I spent some time reading docs yesterday and I found designer supports hiding field mapped on relations. I think this is what I need in this situation. I think I'll choose the second solution from my earlier post: I create separate methods in manager's classes to fetch related entities. Hiding related entities's fields assures me that nobody use them before related entities are actually fetched.

This approach has one disadvantage - I can't preserve fetched entities for later use (every call of method results in database query). Is there a possibility to mark fields mapped on relations as private instead of removing them from entity class? - this would be a perfect solution for me (or at least I think so )

This approach has one disadvantage - I can't preserve fetched entities for later use (every call of method results in database query).

You may implement a cashing technique.

Is there a possibility to mark fields mapped on relations as private instead of removing them from entity class? - this would be a perfect solution for me (or at least I think so )

I think you can do that by modifying the generating code templates.

Thank you for your help but I've found another problem I have just discovered that hiding fields mapped on relations causes that functions GetRelationInfo* are not generated in Entity classess Is that mean I have to create IRelationPredicateBucket object myself?

I hope my questions are not too stupid I started to use LLBLGenPro some weeks ago and I try to find the best way of using it.

franek wrote:

Thank you for your help but I've found another problem I have just discovered that hiding fields mapped on relations causes that functions GetRelationInfo* are not generated in Entity classess Is that mean I have to create IRelationPredicateBucket object myself?

the entity then doesn't have a reference mapping to related entities, and thus doesn't offer these constructs. Then yes, you have to construct the buckets yourself, but you shouldn't need to as you can't fetch related entities into the current entity anyway.

Otis wrote:

the entity then doesn't have a reference mapping to related entities, and thus doesn't offer these constructs. Then yes, you have to construct the buckets yourself, but you shouldn't need to as you can't fetch related entities into the current entity anyway.

I realize I can't fetch related entities into the current entity (there is no fields mapped on relations in entity class) but I would like to create method in manager class to get related entities as EntityCollection (for example GetCustomerOrders in CustomerManager class). I thought it would be quite useful to construct buckets automatically using GetRelationInfo* methods.

The problem is that if a field mapped onto a relation is hidden, it's 'unknown' by definition. So the GetRelationInfo<somename> can't be created because 'somename' has no meaning as it doesn't exist.

Otis wrote:

The problem is that if a field mapped onto a relation is hidden, it's 'unknown' by definition. So the GetRelationInfo<somename> can't be created because 'somename' has no meaning as it doesn't exist.

Thanks for your help. It's clear to me now.