I am working with a client who is using CSLA 1.5. As I was looking through their code base I noticed something odd in how the modeled their parent child relationships. We are supposed to follow their "standards" but I am not real sure that what they did is good design.
I am looking for some insight into their approch. Perhaps validation to my gut feel that it is not good design. Or perhaps pointing out something I missed that may show it is. Below is what they did assume all objects are read only base objects.
InvoiceInfo has a child collection ProductInfoCollection. However instead of creating a ProductInfoCollection class. The create a private struct inside the InvoicInfo object. The DataPortal_Fetch then creates and populates a list of the struct. See p-code below.
class InvoiceInfo : ReadOnlyBase{
struct ProductInfo{
private string productName;
}
DataPortal_Fetch(){
this.list.add(new ProductInfo)
}
}
This does not seem like good OOAD. Also, if there was any need for ProductInfoCollection to be a switchable base this would totally fall apart. Any insight on some more pros or cons on this approach.
PD
The 1.x book was written this way intentionally. The logic, if I remember, for doing it is that in NORMAL uses, the read only collection is just a collection of static data. The performance benefits of 'using structs' instead of 'newing up' classes was the main reason for that design.
I have a lot of 'Nested Info Structs' around, and it hasn't hindered me in these apps yet.
Rocky stated that using structs in Readonly Collections would offer better performance in his 1.0 book. However, this was not true because of the boxing penalties when adding a value type to a collection. He later changed the structs to classes in the 2.0 book. Ironically, you can now add structs to generic collections without the boxing penalty in .Net 2.0.
Copyright (c) Marimer LLC