My model is that a profile (individual or organization) may have relationships with one or more profiles. Some of those relationships carry additional data (and hence end up being different concrete classes), but all of them implement a common interface that exposes the common properties for all relationships.
Now, a UI requirement I have is that we could have a treeview or hierarchical browse capability. That is, the first level will be all the related people to the profile I'm currently editing/viewing, but I should be able to see who those related people are related to, and click down to see who is related to those people, and so forth.
My challenge is that there is really not any difference in terms of how I'd want the object to operate outside of one item (next paragraph) - I'd like the related people to each have a collection of IProfileRelationships too. Of course, these would be lazily loaded (I assume via a command of some sort to get the data reader that would populate the lazy loaded collection).
What I want to be different is that because these relationships don't have anything to do with the profile I'm editing, I don't want to allow editing of the relationships and have to deal with persistance of them. Only the immediate relationships for the particular profile that I'm editing should be editable and savable.
I am loathe to create a separate parallel set of objects that truly does the exact same thing except that they cannot be saved / are read only.
So, Question #1: Is it OK to utilize an editable child object in a read-only usage?
If so, the following is true:
>> I would be responsible in the UI for not allowing the editing of these nested relationships, the deletion, or addition of nested relationships (relationships not directly related to the profile I'm editing.
>> My objects would help facilitate the lazy loading of these child collections, but when it comes time for saving, it would simply ignore them.
Question #2: Should I enable some sort of exception thrower in my editable child object that is enabled when I mean to use the object in read-only fashion? I was considering a possible approach to do this, since I am code generating most of the fields & properties, might be to override propertyhaschanged and look at a boolean isReadOnly and if true, throw an exception -- that way the UI developer knows pretty quickly that they're doing something they're not supposed to.
Any suggestions much appreciated,
Chris
Copyright (c) Marimer LLC