Hi, until now I had only written simple CSLA based apps where the object child details were simple rows and referenced no other objects themselves. I have a different requirement now however, it is best explained with the Order, OrderDetails scenario. Please excuse my silly questions as I am slightly confused!
The Order object would have a list of OrderDetail objects, that im happy with. But each OrderDetail object would have a Product property, whereby the actual product being ordered would be selected. I can think of the problem however in that the combo box would need to be populated with a list of Products (a true instantiated list of objects), and im thinking it is not entirely sensible to pull all that across over the data portal.
Its past midnight now and rather than pick up the CSLA book I would rather ask for confirmation of my thoughts, in that the correct way of dealing with this is have a property ProductID in the OrderDetail object, which would be an int (or guid, whatever data type the identity is) instead of an actual object? That way I could load the combo box with a name value list. How does that sound?
I guess to be honest I was thinking about business objects too much and confused myself a little, in terms of modelling the business object so strictly that an object contained a list of OrderDetals, which in turn referenced a true, instantiated Products object. I guess this is the purist form but would lead to massive performance issues, and isn’t entirely sensible.
I’m about to start some code generation (first time I’ve never used it before) with CSLA Gen and Codesmith, would anybody be kind enough to comment on how the above scenario is dealt with this tool?
Many thanks for putting up with my ramblings!
Chris
Hi Chris
Have a look at the ProjectTracker example that comes in the CSLA download. It has has a couple of master/detail type forms. ProjectEdit is probably the one to look at. Role is the combobox on tne DataGridView.
Cheers
Ozi
You are right about using the NVL instead of the full blown object.
Also the use of a ProductID as the key and the Product Descr as the Value are correct.
Sometimes I will make the NVL a Property of the Order class.
Other times I will have a larger BO which is used to fetch all the BOs for a screen. This is often called a Use Case Controller as it fetches everything needed for the use case. I called it a Unit Of Work but that is probably not 100% correct - but I have a lot of UOW business objects in my project and I am not anboutto re-name them all. This UOW is simply a normal Root BO that contains other root BOs and NVLs and ROCs and ... (you get the idea).
It is responsible for saving all the contained BOs in a transaction.
HTH
Joe
We have an Order Detail - Product scenario too and as we had lots of products we just had a ProductID property on the OrderItem object (plus some readonly ProductName and ProductDescription properties to make the Order UI display nice text).
In the UI we didn't use a combo to select the product. Instead we used a button that loaded up a search form which called and returned a ReadOnlyCollection of products which the user could then select from. The form then returned the selected PproductID and this was set on the OrderDetail.
On setting the Product ID we would load up the full Product BO to get the description details (or you might have a lighter object just to get the Name and Description) if you really need to optimise.
So many ways of doing the same thing.
We also extended the OrderDetail object to have AddProduct methods which was overloaded so we could AddProduct(ProductID) or AddProduct(ProductObject) or AddProduct(ProductInfoObject).
Hope that helps.
Copyright (c) Marimer LLC