I often have properties in my business objects that exist merely as a concession to the UI. Just to make the data more readable. You can also think of lookup-data, that is not touched by any logic.
I thought of, besides the original BO, having a new readonly object that would provide the UoW/UI with supplemental data related to the actual use case. This object, when implemented as a child property of the "real" BO or the UoW object, would always only have to travel from server-side to client-side, providing the UI with updated additional data each time. Even use-case specific lookup-lists could be updated this way.
What is important to notice here, is that there are properties that will always travel the DataPortal one-way.
I know that we can already implement such a feature by hand, overriding certain methods called in the process of any DataPotal operation, and setting the desired property values to null before serialization starts.
Having the framework provide that feature would be much nicer! :-)
I imagine it could be implemented very easily around the usage of the existing NonSerializableAttribute.
What do others think about that.
What type of UI/Clients are you using?
Have you look at the UOW approach?
* using a ReadOnly object that fetch the Root BO and additional data required for the UI?
This way you only need 1 async or sync operation to get all the data needed for the UI (UseCase) and it will be one-way for additional data as they are not part of the Root BO.
A better explanation here from Joe Fallon:
Yes, I must agree that the UoW approach works (as always).
But I think a "SemiSerializableAttribute" would gain us some flexibility to model scenarios where a UoW object is overkill.
I Initially was inspired by this parallel thread Handling Read-Only Info Properties in Business Objects
What I had in mind was lots of readonly properties of a root editable object like a "CustomerTypeDescription" or all kind of status information likely to change while a user is editing the object for a certain amount of time (perhaps multiple updates).
I see that this is an edge case (updating readonly property values + long time editing an object with multiple updates).
I just realized that the NonSerialized feature is unavailable when using managed properties...
So the only way to achieve what I had in mind is to reset the involved properties just before serialization on the (logical) client-side...
Arrrrgh.... or more adequate: D'oh!
Given the increasing use of async server communication, and the rise in popularity of the MVVM design pattern, I do think a UoM object to retrieve other objects, combined with a viewmodel that exposes these read-only or UI-specific derived properties may be the better combination overall.
Copyright (c) Marimer LLC