Hello, I'm evaluating LLBLGen Pro for our project and I was just wondering if there is any document explaining the structure and contents of the generated code, please.

In particular I'm interested in the RelationClasses package. When are classes in this package used? Can it be eventually excluded from the code generation and leave the hassle of managing relation between entities to the developer? My aim is to strip down the generated code "as much as possible" in order to get a minimal DAL.

Regards, Xserty

xserty wrote:

Hello, I'm evaluating LLBLGen Pro for our project and I was just wondering if there is any document explaining the structure and contents of the generated code, please.

It is briefly explained in the SDK documentation. I'll send you a .zip file with that documentation.

In particular I'm interested in the RelationClasses package. When are classes in this package used? Can it be eventually excluded from the code generation and leave the hassle of managing relation between entities to the developer? My aim is to strip down the generated code "as much as possible" in order to get a minimal DAL.

RelationClasses are used inside the generated code by m:n relation targeting code, like in selfservicing, when you read the property which represents related objects over a m:n relation.

RelationClasses are also used in prefetch path definitions.

They're also used to formulate relations to walk in a query, for example you want all customers with orders in May 2003, you need the orders joined to customers to filter on the order date. You then use a RelationCollection with the relation CustomerEntity.Relations.OrderEntityUsingCustomerID and a fieldcomparevalue predicate which compares order.orderdate with the value specified.

In other words: they're essential code.

If you want a minimal dal, use adapter. It has less code than selfservicing. At the moment, the templates internally rely on the predicatefactory helperclass. This will be changed so for really large projects (1000+ entities) you can opt for not generating that class. However the helper class is really useful for developers to construct filters.

Otis wrote:

xserty wrote:

Hello, I'm evaluating LLBLGen Pro for our project and I was just wondering if there is any document explaining the structure and contents of the generated code, please.

It is briefly explained in the SDK documentation. I'll send you a .zip file with that documentation.

Received with many thanks!!

Otis wrote:

xserty wrote:

In particular I'm interested in the RelationClasses package. When are classes in this package used? Can it be eventually excluded from the code generation and leave the hassle of managing relation between entities to the developer? My aim is to strip down the generated code "as much as possible" in order to get a minimal DAL.

RelationClasses are used inside the generated code by m:n relation targeting code, like in selfservicing, when you read the property which represents related objects over a m:n relation.

Does this mean that LLBLGen Pro does not need a normalised database schema?

Otis wrote:

RelationClasses are also used in prefetch path definitions.

They're also used to formulate relations to walk in a query, for example you want all customers with orders in May 2003, you need the orders joined to customers to filter on the order date. You then use a RelationCollection with the relation CustomerEntity.Relations.OrderEntityUsingCustomerID and a fieldcomparevalue predicate which compares order.orderdate with the value specified.

In other words: they're essential code.

If you want a minimal dal, use adapter. It has less code than selfservicing. At the moment, the templates internally rely on the predicatefactory helperclass. This will be changed so for really large projects (1000+ entities) you can opt for not generating that class. However the helper class is really useful for developers to construct filters.

Thanks for helping Xserty

xserty wrote:

Otis wrote:

xserty wrote:

In particular I'm interested in the RelationClasses package. When are classes in this package used? Can it be eventually excluded from the code generation and leave the hassle of managing relation between entities to the developer? My aim is to strip down the generated code "as much as possible" in order to get a minimal DAL.

RelationClasses are used inside the generated code by m:n relation targeting code, like in selfservicing, when you read the property which represents related objects over a m:n relation.

Does this mean that LLBLGen Pro does not need a normalised database schema?

If you mean by that that you can specify different entities on the same table, I have to say: yes it requires a normalized schema.

But if you could elaborate a bit about what you mean with a denormalized schema, I would be better able to answer the question