I have a WinForms Order Processing Application which uses typed datasets. I would like to restructure the application and use LLBLGen for the first time, but I am not quite sure about how best to do it. Maybe some of you n-layer-cracks can give me a bit of advice.

My basic entities are Shipment, Order, OrderItems and Customer. A shipment contains several orders of different customers.

My application displays shipments, orders and order items in three editable grids, the orders grid displays a combination of order and customer data. All grids also display data calculated at runtime.

1. As I cannot directly display the entities, would I use a dataset to bind to the UI? Typed lists don't seem such a good idea, as, if I understand correctly, they get their data directly from the database, so if I have any unsaved edits in my entitiy objects, these would not be reflected in the UI.

2. Would the BL fill the dataset, reading data from my entity objects and calculating additional data, and transfer user edits back to the entity objects? The shipments grid displays total amounts for the entire shipment. If I use the entity objects for calculation, I would have to load the entire data for all the orders and order items at startup. Would it be "admissible" to query the database directly instead?

3. Shipment and Order have stati which are interdependent, e.g. shipment status cannot be changed to "checked" unless all orders are checked. The sensible place to put such rules would be the BL; but I would like to give the user immediate feedback, when invalid data is entered. How can I accomplish that?

There's more, but I'll stop here. If I get some answers, my other problems might get solved too.

Rab wrote:

I have a WinForms Order Processing Application which uses typed datasets. I would like to restructure the application and use LLBLGen for the first time, but I am not quite sure about how best to do it. Maybe some of you n-layer-cracks can give me a bit of advice.

My basic entities are Shipment, Order, OrderItems and Customer. A shipment contains several orders of different customers.

My application displays shipments, orders and order items in three editable grids, the orders grid displays a combination of order and customer data. All grids also display data calculated at runtime.

1. As I cannot directly display the entities, would I use a dataset to bind to the UI? Typed lists don't seem such a good idea, as, if I understand correctly, they get their data directly from the database, so if I have any unsaved edits in my entitiy objects, these would not be reflected in the UI.

You can also map fields in Order on Customer fields, which are in fact retrieving order.Customer._SomeField_, so updating the customer's field, is reflected in the order. This might solve your problem and make you bind order entities to the grid

1. Would the BL fill the dataset, reading data from my entity objects and calculating additional data, and transfer user edits back to the entity objects? The shipments grid displays total amounts for the entire shipment. If I use the entity objects for calculation, I would have to load the entire data for all the orders and order items at startup. Would it be "admissible" to query the database directly instead?

I'm not quite following this one. To be able to calculate things outside the db, you need to have the required data outside the db in that routine, so I'm a bit confused what you mean here.

1. Shipment and Order have stati which are interdependent, e.g. shipment status cannot be changed to "checked" unless all orders are checked. The sensible place to put such rules would be the BL; but I would like to give the user immediate feedback, when invalid data is entered. How can I accomplish that?

I think you then have to check after each change the user makes, and report back, e.g.: perform the complete validation each time the user enters something.

Rab wrote:

I have a WinForms Order Processing Application which uses typed datasets. I would like to restructure the application and use LLBLGen for the first time, but I am not quite sure about how best to do it. Maybe some of you n-layer-cracks can give me a bit of advice.

My basic entities are Shipment, Order, OrderItems and Customer. A shipment contains several orders of different customers.

My application displays shipments, orders and order items in three editable grids, the orders grid displays a combination of order and customer data. All grids also display data calculated at runtime.

1. As I cannot directly display the entities, would I use a dataset to bind to the UI? Typed lists don't seem such a good idea, as, if I understand correctly, they get their data directly from the database, so if I have any unsaved edits in my entitiy objects, these would not be reflected in the UI.

Otis wrote:

You can also map fields in Order on Customer fields, which are in fact retrieving order.Customer._SomeField_, so updating the customer's field, is reflected in the order. This might solve your problem and make you bind order entities to the grid

I also have to display columns with calculated data, some of which comes from software servers. You can't have calculated fields in entities, can you?

Rab wrote:

1. Would the BL fill the dataset, reading data from my entity objects and calculating additional data, and transfer user edits back to the entity objects? The shipments grid displays total amounts for the entire shipment. If I use the entity objects for calculation, I would have to load the entire data for all the orders and order items at startup. Would it be "admissible" to query the database directly instead?

Otis wrote:

I'm not quite following this one. To be able to calculate things outside the db, you need to have the required data outside the db in that routine, so I'm a bit confused what you mean here.

I have to display the sum total of a shipment. I could calculate it by iterating through all the orders and order items, adding up the prices of all the items, or I could use a DB query like "select sum(price) from OrderItem where...", which would certainly be much faster. But my question is really a general one: if you use LLBLGen, would you do everything within the entity model, or would you also use direct database access where it seems advantageous? (I guess I could use a typed list with an aggregate function just to calculate the sum, in this case, but that's direct database access outwith the entity model, isn't it?)

Rab wrote:

1. Shipment and Order have stati which are interdependent, e.g. shipment status cannot be changed to "checked" unless all orders are checked. The sensible place to put such rules would be the BL; but I would like to give the user immediate feedback, when invalid data is entered. How can I accomplish that?

Otis wrote:

I think you then have to check after each change the user makes, and report back, e.g.: perform the complete validation each time the user enters something.

Rab wrote:

Rab wrote:

I have a WinForms Order Processing Application which uses typed datasets. I would like to restructure the application and use LLBLGen for the first time, but I am not quite sure about how best to do it. Maybe some of you n-layer-cracks can give me a bit of advice.

My basic entities are Shipment, Order, OrderItems and Customer. A shipment contains several orders of different customers.

My application displays shipments, orders and order items in three editable grids, the orders grid displays a combination of order and customer data. All grids also display data calculated at runtime.

1. As I cannot directly display the entities, would I use a dataset to bind to the UI? Typed lists don't seem such a good idea, as, if I understand correctly, they get their data directly from the database, so if I have any unsaved edits in my entitiy objects, these would not be reflected in the UI.

Otis wrote:

You can also map fields in Order on Customer fields, which are in fact retrieving order.Customer._SomeField_, so updating the customer's field, is reflected in the order. This might solve your problem and make you bind order entities to the grid

I also have to display columns with calculated data, some of which comes from software servers. You can't have calculated fields in entities, can you?

You can add properties to the entity classes yourself if you'd like, via include templates or via the user code regions in the generated code. Please see 'Using the generated code -> Adding your own code to the generated classes'.

Rab wrote:

1. Would the BL fill the dataset, reading data from my entity objects and calculating additional data, and transfer user edits back to the entity objects? The shipments grid displays total amounts for the entire shipment. If I use the entity objects for calculation, I would have to load the entire data for all the orders and order items at startup. Would it be "admissible" to query the database directly instead?

Otis wrote:

I'm not quite following this one. To be able to calculate things outside the db, you need to have the required data outside the db in that routine, so I'm a bit confused what you mean here.

I have to display the sum total of a shipment. I could calculate it by iterating through all the orders and order items, adding up the prices of all the items, or I could use a DB query like "select sum(price) from OrderItem where...", which would certainly be much faster. But my question is really a general one: if you use LLBLGen, would you do everything within the entity model, or would you also use direct database access where it seems advantageous? (I guess I could use a typed list with an aggregate function just to calculate the sum, in this case, but that's direct database access outwith the entity model, isn't it?)

You can also fire off a scalar query to calculate the sum, which results in select sum(..) from ... . The entity model that's available to you can be used to build scalar queries but also dynamic lists, the SQL is then generated for you. See for example 'Aggregate functions in scalar queries' in 'Using the generated code -> Field expressions and aggregates' for details/ an example.

Hi Otis,

To sum it all up, you would recommend to

1. use entities in the UI, just modify them, to make them fit
2. never access the database directly, but always go through entities or typed lists

Thanks a lot for all the feedback!

Rab wrote:

Hi Otis,

To sum it all up, you would recommend to

1. use entities in the UI, just modify them, to make them fit

Yes, and use typedlists / dynamic lists for read-only data in list form.

1. never access the database directly, but always go through entities or typed lists

No, you should access the database directly in some cases, for example through scalar queries, or for example if you want to update entities in bulk without fetching them first. What I meant was: you build these queries using entity elements, like fields .