Collections are independent types from the domain objects on which they are used to define properties, yet they are usually closely tied to internal business logic of the single domain object that "owns" them.
What do you do in each of the following scenarios:
- You have business logic that determines whether or not an item can be added to the collection.
- You have some logic that needs to run before an item is added to the collection and another piece of logic that need run after the item was added.
These are the possible approaches that I can think of for tackling these scenarios:
- Put that logic in the view-model. The logic will need to be repeated everywhere the collection is modified.
- Expose the collection as
IEnumerable
then add Add/Remove methods directly onto the domain object where you put the check logic. This works but the public collection
property can always be cast to ICollection
or derivative and directly modified, thus violating the intended encapsulation. - Create a custom collection.
But I do not feel satisfied with any of these options. I always wished to see a language feature like the add/remove block that was introduced in C# for events but as being available for public collection
properties as well.
public collection IList<orderdetails> Details
{
add { if (isMaxReached) throw new Exception("max reached"); details.Add(value); }
remove { details.Remove(value); }
}
All modifications to the collection
would pass through these accessors.