We have a scenario which I am sure is common. We have a screen that has the details of an item (say an Order for simplicity). These details are editable when inserting the item, but once inserted, they are read only. So upon first entry, they are editable, and subsequent views of the data, they are read only.
Do you have two separate BOs for this, or do you make an editable BO that can "change" to read only? I have seen a few threads on here and understand how to implement a "switchable" read only/editable object, but I am wondering from a "correct" standpoint if it is better to have two different BOs? The purist in me seems to think that one editable object for entry and one read-only object is the way to go, but the time-saver and re-user in me thinks that a hybrid is the easiest way to go about it.
Thoughts?
A lot of people use authorization to solve this - overriding CanWriteProperty() so it always returns false when IsNew is false, otherwise returning the security-based value.
I think that's a fine thing. You could argue that the user is only authorized to edit values of a new object, and that they are not authorized to edit values of an existing object.
As long as it is not a big CSLA no-no, I am going to try that route. Thanks Rocky.
I'm thinking however, of implementing it with a readonly flag in the base class and a MarkReadOnly() function with the CanWriteProperty override so that classes don't have to override CanWriteProperty each time I need a "switchable" class.
Copyright (c) Marimer LLC