1. As you mentioned, invoice will involve customer, order details, stock. Do you meant that I will have Invoice BO, and also have property to hold the customer, order details and stock BO? Then, we could access data layer thru the BO ?Yes in fact if I were designing the system there would be a customer BO and the invopice BO would have a property named oCustomer that was a reference to a customer BO.
>2. Should I have order details BO and data object? How invoice BO access the order details record, thru order details BO, order details data object or using view/ADO that join order and order details in invoice data object?I would not make an order details BO beacuse as far as the businmess is concerned there is no such thing, it is intricately part of the Order itself and does not esxist without the order. As for an order details data object that I may create one or not as to how I found it easier to work with the data storage.
3. As the table structure shown in previous message, my stock control system application support multiple branches, multiple selling price for each branches. Then, I should have BO like branch, item, stock and ..?? price is a BO? I feel not, then how I able to access the items' multiple selling price since it is normalized and not stored in item table?`Again, the data objects will deal with the details of where the data exists and they need to be smart. The business objects cam manipulate the data objects in a smart fashion as well. So we have a sales order BO and it has a Branch BO as its child now when the sales order need to access inventory it tells inventory BO what Branch this order is for and the inventory BO is smart enough to deal with the price issue. This way the sales order BO only ever sees one price in the inventory BO.