question about passing object references,Me and serialisation


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 8 of 8

Thread: question about passing object references,Me and serialisation

  1. #1
    will Guest

    question about passing object references,Me and serialisation


    Hi,

    I have a class called Person. It inherits from a base class PersistentObject
    that exposes Load() and Save() functions and contains an ObjectID.

    I WANT to write the Load() method like this:

    class PersistentObject
    sub Load()
    PersistentManager.LoadObject(Me) 'where Me is a By Ref parameter
    end sub

    The persistence layer uses .NET serialisation to return a populated object,
    based on the persons ObjectId which must be populated when Load() is called.
    (or does a refresh). It also examines other properties of the PersistentObject,
    such as whether this is a proxy object or not.

    Now the problem. Me cannot be assigned a new object. Likewise making the
    parameter in LoadObject() By Ref and passing it Me does not work (interestingly
    it compiles without complaint but simply does not change).

    So I have resorted to making Load() a method that returns the newly loaded
    object, meaning I have to write the ugly code:

    class PersistentObject
    function Load()
    dim oObj as PersistentObject
    oObj=PersistentManager.LoadObject(Me)
    return oObj
    end function

    and in the main program:

    person=person.Load()

    when what I want to be able to write is
    person.Load()

    It's nice having Load() a method of the object, rather than having to call
    a function in the persistance layer. Any idea's on how I could get the object
    to change itself to the new object, within the Load() method, or solve this
    design problem someother way? Guess I am missing something because this must
    be a common scenario

    If not I guess the best thing is to put a method on the PersistanceManager
    so I can write
    PersistenceManager.Load(person)
    Then there are no problems having Person being passed by ref and returning
    a new object. (PersistenceManager is a singleton)

    Any ideas?

    Thanks,
    Will







  2. #2
    Rune Bivrin Guest

    Re: question about passing object references,Me and serialisation

    "will" <williamfleming@hotmail.com> wrote in
    news:3db0fce4$1@tnews.web.devx.com:

    >
    > Hi,
    >
    > I have a class called Person. It inherits from a base class
    > PersistentObject that exposes Load() and Save() functions and contains
    > an ObjectID.
    >
    > I WANT to write the Load() method like this:
    >
    > class PersistentObject
    > sub Load()
    > PersistentManager.LoadObject(Me) 'where Me is a By Ref parameter
    > end sub
    >


    I'd say, without any deeper analysis, that this is a good candidate for a
    shared method on the Person class.

    If not, Load would set the properties on the object itself, rather than
    creating a new object and trying to return that.

    --
    Rune Bivrin
    - OOP since 1989
    - SQL Server since 1990
    - VB since 1991


  3. #3
    MarkN Guest

    Re: question about passing object references,Me and serialisation


    The common scenario is to use a 'Manager' to retrieve (load) an object.

    A persistant frame work on another OO platform uses an Object ID and the
    object type to 'load' and return the object. For example:

    Person person = ManagerFactory.getPersonManager.retrieve(new ObjectID(1))

    (Person being an interface and PersonMangager being returned as an interface)

    I wouldn't inherit Person from PersistentObject.

    "will" <williamfleming@hotmail.com> wrote:
    >
    >Hi,
    >
    >I have a class called Person. It inherits from a base class PersistentObject
    >that exposes Load() and Save() functions and contains an ObjectID.
    >
    >I WANT to write the Load() method like this:
    >
    >class PersistentObject
    > sub Load()
    > PersistentManager.LoadObject(Me) 'where Me is a By Ref parameter
    > end sub
    >
    >The persistence layer uses .NET serialisation to return a populated object,
    >based on the persons ObjectId which must be populated when Load() is called.
    >(or does a refresh). It also examines other properties of the PersistentObject,
    >such as whether this is a proxy object or not.
    >
    >Now the problem. Me cannot be assigned a new object. Likewise making the
    >parameter in LoadObject() By Ref and passing it Me does not work (interestingly
    >it compiles without complaint but simply does not change).
    >
    >So I have resorted to making Load() a method that returns the newly loaded
    >object, meaning I have to write the ugly code:
    >
    >class PersistentObject
    > function Load()
    > dim oObj as PersistentObject
    > oObj=PersistentManager.LoadObject(Me)
    > return oObj
    > end function
    >
    >and in the main program:
    >
    > person=person.Load()
    >
    >when what I want to be able to write is
    > person.Load()
    >
    >It's nice having Load() a method of the object, rather than having to call
    >a function in the persistance layer. Any idea's on how I could get the object
    >to change itself to the new object, within the Load() method, or solve this
    >design problem someother way? Guess I am missing something because this

    must
    >be a common scenario
    >
    >If not I guess the best thing is to put a method on the PersistanceManager
    >so I can write
    > PersistenceManager.Load(person)
    >Then there are no problems having Person being passed by ref and returning
    >a new object. (PersistenceManager is a singleton)
    >
    >Any ideas?
    >
    >Thanks,
    >Will
    >
    >
    >
    >
    >
    >



  4. #4
    will Guest

    Re: question about passing object references,Me and serialisation


    Hi Mark, Thanks for your reply.

    I am using a Manager - the PersistanceManager object called by PersistantObject.Load().
    I guess there is a difference of philosophy here - should an object know
    everything about how to persist itself, in which case I should be able to
    write Person.Load() and require no knowledge of the Manager class, or is
    it better to force the client code to call the MangerFactory as you suggest,
    which requires the client code to have knowledge about the ManagerFactory:

    >Person person = ManagerFactory.getPersonManager.retrieve(new ObjectID(1))
    >


    One question about ManagerFactory - Does it return a separate interface for
    every kind of data class? Does this mean if you add a new data class to the
    application, you need to modify ManagerFactory code? That is what I was hoping
    to avoid by writing a "ManagerFactory" (I have called it PersistenceManager)
    that works only with the base class PersistentObject and has no knowledge
    of individual data classes. As I only require simple persistence using .NET
    serialization I was hoping this was a feasible design. Feels so much nicer
    than a persistence layer that requires changing everytime I add/modify/delete
    a data class!

    cheers,
    Will


  5. #5
    will Guest

    Re: question about passing object references,Me and serialisation


    Hi Rune,

    Thanks for your reply.

    >
    >I'd say, without any deeper analysis, that this is a good candidate for

    a
    >shared method on the Person class.


    The Load() function can also refresh an existing person. So I think it's
    better if you can go person1.load() person2.load() etc rather than making
    load a shared function. Though its an interesting idea I hadn't though of
    before...

    >If not, Load would set the properties on the object itself, rather than


    >creating a new object and trying to return that.


    I agree this is what would normally happen if you were pesisting to a relational
    database for example. The problem is .NET serialisation returns a whole new
    object from the Deserialize() function. I guess I could then take that object
    and manually copy the data into the existing objects properties, but that
    starts getting messy if your object contains a collection of child objects
    which also contain objects and so on. Thats what serialization is supposed
    to magically take care of for free!




  6. #6
    MarkN Guest

    Re: question about passing object references,Me and serialisation


    In a pure OO world, I would say you are right, the Object should know how
    to persist itself. It won't work the way you want it to though. You do
    want to hide the persistance mechanism. So how does one go about it? What
    are the ways something can be persisted? We can't name them all but let's
    try:
    Serialized object (binary), XML Serialization, RDBMS, O/R Mapping, ODBMS,
    Files, Heirchical DB, Retrieved via Messaging, veriations of each, and a
    combination of each of these. Each of these brings its own issues. Today
    you are doing object serialization. How about tommorrow? We cannot see
    tomorrow. History shows us that if we don't prepare for tomorrow, we won't
    be prepared. Som what will work for one may not work well for the other


    The most common thing is to do it the way I showed and then implement as
    needed. The problem is that you are instantiating one object then replacing
    it with another. Just because the object is not persisted doesn't mean it
    doesn't exist.

    Ok, while I was hacking this I was thinking too. How about this -

    Person person = Person.load(new ObjectId(1));

    // method in Person class
    public static Person load(ObjectId objectId)
    {
    return ManagerFactory.getPersonManager.retrieve(objectId);
    }

    //Method in PersonManagerSerializedObject (which implements PersonManager)
    public static Person retrieve(ObjectId objectId)
    {
    return (Person) PersistentManager.LoadObject(new Person(objectId));
    }


    //Method in ManagerFactory
    public static PersonManager getPersonManager()
    {
    // Either by reflection (prefered for flexibility - I'll give you an excellent
    example if you want) or by instantiating the concrete class, return the current
    PersonManager which would be PersonManagerSerializeObject
    }


    Ok the reason that you should probably call the factory and manager to get
    the Person object is because the person Object should be returned as an
    interface too. So i.e. Person should be an interface and PersonSerializeObject
    will implement it. The controller class should also as the Manager for a
    new instance. You may not see a reason for this today, but as .Net matures
    more persitance frameworks will come available it will future proof you.
    (For reference, check out Java persistance frameworks).

    We are doing this with excellent results. We have 'psuedo heavy' clients.
    I want to be able to design my app without worrying about implementation
    details so I write it as if everything is on the same machine but hide the
    details but also with multiuse in mind. Then I think about distributing
    the app and how and where things should run. Then I write custom Managers/Classes
    or whatever for the need and then distribute. This explanation is some what
    simplistic - but these technique works. .Net throughs a wrinkle into because
    you gotta know what exceptions will be thrown. The way around that is to
    catch those exceptions and only throw what the interface docs say can be.

    Here is a good link. Sorry it is in Java but the principles are the same.
    http://www.javadude.com/articles/


  7. #7
    will Guest

    Re: question about passing object references,Me and serialisation


    Hi Mark.

    Thanks very much for your informative message. You are suggesting a fairly
    major architectural change! I'll think it all over, read some more articles
    and let you know what happens.

    Will




  8. #8
    MarkN Guest

    Re: question about passing object references,Me and serialisation


    You're welcome. I've tried this in different ways and different languages
    and have come up with this. Yes, it might be an architectual change now,
    but it will prevent more and more painful ones in the future.

    Mark


    "will" <williamfleming@hotmail.com> wrote:
    >
    >Hi Mark.
    >
    >Thanks very much for your informative message. You are suggesting a fairly
    >major architectural change! I'll think it all over, read some more articles
    >and let you know what happens.
    >
    >Will
    >
    >
    >



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center