When building a readonly collection, csla uses structures instead of classe as they have less overhead. This is the question I have about that:
I use a lot of readonly children. Ex: Person object has a readonly city child. I don't make it editable, after all, the only place I want to allow anyone to edit the city is in the city edit form.
So now when I create the person, I need to select from a list of cities. This is a ro collection (sure it could be a namevalue list, but often the collection requires several fields of information, plus I usually have to make the readonly collection for other uses ). To set the persons city, I get the city id from the structure, then I need to go to the database to get the readonly city. So it is big time overhead everytime I need to fetch a readonly object from a readonly collection.
So what I do is make my readonly collections using readonly children instead of a structure. The readonly children have a fetch(dr) the same as editable children. Now when I select a child from the collection, I already have it, no need for a trip to the database.
For me, this is a common scenario. What I wonder is how does the cost of creating readonly children for my collections compare with all the database accesses I have to make everytime I select something from a collection?
Another point: Many of these readonly collections use the singleton pattern, so that cuts my creation overhead as I only have to create it once, unless I need to refresh it of course.
Just use classes and enjoy.
I suppose that there are some places where the efficiency of structures would be significant but considering everything else (network latency, database calls, forms drawing etc) and it will never be noticed.
And use the structure in the wrong way and all those savings are not only lost but in-efficiency is encountered in the form of boxing and unboxing.
In CSLA .NET 2.0 and ProjectTracker 2.0 I switched to using classes. There's no value in using a struct unless you specifically want value-type semantics, which aren't valuable in most cases.
However, you'll notice that the 2.0 SmartDate is now a struct, because in that case value-type semantics are valuable.
Copyright (c) Marimer LLC