CSLA .NET

Vibrant discussion about CSLA .NET and using the framework to build great business applications.

Forum has moved

New location: CSLA .NET forum


CSLA .NET Resources:
  • CSLA .NET forum
  • CSLA .NET home page
  • Feature request/proposal: "SemiSerializable" properties

    rated by 0 users
    Answered (Verified) This post has 2 verified answers | 3 Replies | 2 Followers

    Top 50 Contributor
    135 Posts
    stefan posted on Thu, Dec 16 2010 5:08 AM

    Hi @all!

    Background:

    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.

    Proposal:

    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.

     

    Stefan

    Stefan

    Answered (Verified) Verified Answer

    Top 10 Contributor
    2,279 Posts
    Verified by stefan

    Hi Stefan,

    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:
    http://forums.lhotka.net/forums/p/6646/32377.aspx#32377

    Jonny Bekkum, Norway CslaContrib Coordinator

    Top 10 Contributor
    9,475 Posts
    Verified by stefan

    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.

    Rocky

    All Replies

    Top 10 Contributor
    2,279 Posts
    Verified by stefan

    Hi Stefan,

    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:
    http://forums.lhotka.net/forums/p/6646/32377.aspx#32377

    Jonny Bekkum, Norway CslaContrib Coordinator

    Top 50 Contributor
    135 Posts
    stefan replied on Thu, Dec 16 2010 8:40 AM

    Hi Jonny,

    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).

    • My proposed approach would enable us to refresh such data without any additional trips to the server.
    • In addition, databinding would be restricted to one object. (=old style)
    • The amount of data transferred over the wire when having lots of such read-only string properties is reduced significantly
    • We could implement a lookup-list (NVL) that has to be kept up-to-date, as a property of the root object, without having to care about unnecessary network load. Just use the proposed attribute on the NVL-property.

    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... Embarrassed

    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!

     

    Stefan

    Stefan

    Top 10 Contributor
    9,475 Posts
    Verified by stefan

    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.

    Rocky

    Page 1 of 1 (4 items) | RSS

    Copyright (c) 2006-2014 Marimer LLC. All rights reserved.
    Email admin@lhotka.net for support.
    Powered by Community Server (Non-Commercial Edition), by Telligent Systems