Discussions

News: Value Objects and Value Object Factory patterns posted

Bookmark and Share Get thread feed

  1. Value Objects and Value Object Factory patterns posted (19 messages)

    A complete re-write of the value object patterns has been posted on TheServerSide, as well as a new version of Value Object Factory, all part of the EJB Design Patterns book. Also posted are pre-final versions of Tyler Jewell's and Scott Ambler's Mastering EJB II chapters.

    The re-write of Value Objects reflects a paradigm shift in how to think of Value Objects that is now possible thanks to EJB 2.0. Would love your feedback on it!

    Check out EJB Design Patterns.
    Check out Mastering EJB Second Edition.
    Reply to this

    Threaded Messages (19)

  2. Value Objects and Value Object Factory patterns posted[ Go to top ]

    I really like this pattern, but there seems to be some disapproval of its use in some J2EE quarters. For instance EJB guru Richard Monson-Haefel reckons that Value Objects (bulk accessors as he calls it) are not as good as most think since it gives rise to stale objects which might not represent database info and due to the fact that it uses more bandwidht as V objects are seriallized and passed over the network even if only one setter method is required.

    He suggests the use of setters and getters per attribuite on the EJB and using Session beans to call them so as to limit Network overhead.

    Any ideas on this is welcome. Thansk
    Reply to this Reply to original

  3. Value Objects and Value Object Factory patterns posted[ Go to top ]

    Hi,

    My choice is still Value objects. But implementation really depends on your system. For example, I use weblogic and right now there is only one server. So my value objects are in fact proxy which just delegates calls to the ejb. If I cluster or there is significant overhead of using proxy value objects, I will smarty switch implementation of my ejb to return normal value objects to the caller. And note, this change will not require any change in the rest of the system.
    Reply to this Reply to original

  4. Value Objects and Value Object Factory patterns posted[ Go to top ]

    Cool - I happen to agree on this one. I think that Value Objects pattern is ugly and not very object-oriented. I think 2.0 spec emphasises a better approach - all entity acceses should be local, and, optionally facaded by remoteable session beans.
    Reply to this Reply to original

  5. Value Objects and Value Object Factory patterns posted[ Go to top ]

    Dimitri wrote:

    > Cool - I happen to agree on this one. I think
    > that Value Objects pattern is ugly and not
    > very object-oriented. I think 2.0 spec
    > emphasises a better approach - all entity
    > acceses should be local, and, optionally
    > facaded by remoteable session beans.

    Yes but how does a remote client pass information to and from a local Entity object? You have to go through a remote session bean. Since you don't have access to the Entity's remote setters and getters, the session has to be the middle man, and the only common language that can be spoken between a remote client and a local entity is value objects.

    Of course, your value object doesn't have to map 100% of the fields, you can arbitrarily fine-grain them. For example, if you have a full Entity bean representing a person (address, phone number, SSN, etc...) and all you want is change their middle name, create a value object that will contain only the subset you need.

    Incidentally, EJBGen 1.20 generates value objects for you, so it's really easy to implement the remote SLSB/local EB pattern with it.

    However, there is a significant danger with value objects: defeating tuned updates issued by the container. Typically, the SLSB will take a value object, transfer the whole state into the Entity bean and commit. If the container is not clever, it will observe that all the setters were called and will issue an update on all the fields. Of course, this won't happen if you are using Weblogic :-)

    --
    Cedric

    Reply to this Reply to original

  6. Value Objects and Value Object Factory patterns posted[ Go to top ]

    He suggests the use of setters and getters per attribuite

    >on the EJB and using Session beans to call them so as to
    >limit Network overhead.

       I completely agree with RMH here. Note that in the patterns I explicitly stated that putting a "setValueObject"/"getValueObject" methods on entity beans are a bad idea. Rather a factory should be used that calls get/sets through the entity beans local interface.

       As for Value Objects, they are a necessary evil, used only to bundle and pass data from the client to the session facade. How else are you going to bundle data and send it across the network? Also, there are patterns to overcome the 'stale data' concerns.

      Would love your input here.

    Floyd
    Reply to this Reply to original

  7. Value Objects and Value Object Factory patterns posted[ Go to top ]

    I have to agree with Floyd that Value objects are necessary.
    However, I disagree that they are a "necessary evil".

    As Floyd saids, how else are you going to bundle data from
    inside the EJB container and get it outside? Value objects.

    Not all Value objects are bad. If they represent read-only
    or highly stable data like a list of Product or State
    Codes, then the issue as to whether they can become stale
    is moot.

    Based on my 6+ years of using Forte to develop enterprise
    solutions, I can say the concept of object copies i.e. Value
    objects was essential to minimising network traffic.

    If the data had a "chance" of becoming state then we
    developed lock manager or optimistic write-back patterns to
    address it. Also knowing how the data will be used
    will indicate when stalness could be a problem.

    As with all things in the IT world there are no hard and
    fast, one-size-fits-all solutions. You have to have the
    experience to know when what you want to do will not work
    and be adaptable to arrive at new solutions that will.

    Just my thoughts.

    Cheers,

    Noel.



    Reply to this Reply to original

  8. Better: Data Transfer Object[ Go to top ]

    I think one of the first things we all must agree is in "naming conventions". In my opinion, when you mean "Value Object" you really want to mean "Data Transfer Object".

    Please take a look at what Martin Fowler says about this subject at http://www.martinfowler.com/isa/valueObject.html

    You can also find some good stuff about the subject at www.two-sdg.demon.co.uk/curbralan/papers/ValueAdded.pdf

    From my point of view is better to name this kink of objects "Data Transfer Objects" rather than "Value Objects"

    Best regards,

    José Luis Rivera Vidal
    Reply to this Reply to original

  9. Better: Data Transfer Object[ Go to top ]


    Jose,

    Thanks for the URL to www.martinfowler.com. Good to see
    that lots of the folks at ThoughWorks have also used
    Forte and know what distributed computing is all about.

    I for one create my *analysis* model as pure O-O as the
    driven snow. When it comes to design, I take off the
    rose-coloured glasses, step away from the single address
    space mentality and accept the vulgarities of the real
    distributed world.

    Interprocess network latency sucks, but thats the world
    we live in.

    Data Transfer Objects are necessary and are not evil.

    Just my thoughts,

    Cheers,

    Noel.


    Reply to this Reply to original

  10. Better: Data Transfer Object[ Go to top ]

    José,

        While writing my version of the value object patterns I also discovered Martin Fowlers excellent write up. I thought of changing the name to Data Transfer Object, but was concerned that the industry has used the 'value object' term for so long that to rename it now would cause confusion (its hard enough to establish a common name, now that we have one should we try to rename it again?).

        I am still considering changing it, thanks for your input.

    Floyd
    Reply to this Reply to original

  11. Better: Data Transfer Object[ Go to top ]

    Change it. and list "Value Object" in a "also known as" section as seen in the GofF book. Data Transfer Object is so clear, it would be a crime to leave it as is.

    -Peace
    Dave
    Reply to this Reply to original

  12. Better: Data Transfer Object[ Go to top ]

    Yes but how does a remote client pass information to and >from a local Entity object? You have to go through a >remote session bean. Since you don't have access to the >Entity's remote setters and getters, the session has to be >the middle man, and the only common language that can be >spoken between a remote client and a local entity is value >objects.


    Right. I meant that using getValue()/setValue() on entity beans directly is bad.
    Reply to this Reply to original

  13. Better: Data Transfer Object[ Go to top ]

    Dave,

      Have you read through my value object chapters? I think having a pattern called 'Domain Data Transfer Object' and 'Custom Data Transfer Object' sounds weird don't you?

    Floyd
    Reply to this Reply to original

  14. Better: Data Transfer Object[ Go to top ]

    From my point of view is better to name this kink of objects "Data Transfer Objects" rather
                  than "Value Objects"

    I am kind of apathetic about this. I didn't mind "value
    objects" as they implied "pass by value" instead of "pass
    by reference". Guess I've been programmming too long,
    however I don't mind "data transfer objects" either, as
    it implies I am transfering data across layers, service
    to/from application.
    Reply to this Reply to original

  15. Value Objects and Value Object Factory patterns posted[ Go to top ]

    Hi all,
    While going through value objects I have one question in mind-
    If the need is just to get the details in one remote call using a details object,then can't we have a hashmap in entity bean which will be intialised with the values in ejbCreate() and getDetails() method(in entity bean) will just return that hashmap to retrieve bean details.This way it reduces network trafic involved in calling mulitple getters of entity bean.
    Does the returning of hashmap not suffices the requirement of getting details and reducing network calls.(in which case we don't need to create an extra details bean object)

    Although details object will be more useful if we need to do something extra rather than just retreiving values of fields in bean.
    Any one else have thought about this approach.

    Sweety
    Reply to this Reply to original

  16. Value Objects and Value Object Factory patterns posted[ Go to top ]

    Hi Sweety,

      Yes you can use a hasmap, this is described in the Generic Attribute Access pattern, which shows how to use a weak-types hashmap based interface into an entity beans attributes. You could so this, but there are also many reasons you might not. I would suggest reading Generic Attribute Access as well as Value Objects to get a sense of when to use each one.

    sincerely,

    Floyd
    Reply to this Reply to original

  17. Value Objects and Value Object Factory patterns posted[ Go to top ]

    The one thing that has to be kept in mind is that anything but basic (struct) value objects (or bulk accessors) and RMI-IIOP dont mix very well.

    If you have a non-java client accessing your EJB via CORBA-IIOP, then there has to be a client-side-language implementation (say C++, if your client is C++) of these value objects.

    A hashmap is easily one that will trip you up at the moment - I dont think any orbs support it - but at least it stands a chance of having a C++ implementation generated.

    Some of the appservers provide a "simplified IDL" option when generating the IDL for your beans - but obviously this is appserver specific.
    You can read this article for more on RMI-IIOP limitations.
    Reply to this Reply to original

  18. dvo creation[ Go to top ]

    All, what I want to get out of this is patterns for DVO (or DTO) creation. Floyd can you give any good reasons why you recommend using a factory pattern for this?

    I am in a discussion with a SmallTalk programmer who is new to Java. I am very much thinking centralising services, layering our architecture, and using a DVOBuilder class to construct all our DVOs. He on the other hand is thinking 100% Objects and each object should be responsible for its own relative DVO creation i.e. by having a method on each persistent object asDVO().

    I don't have an issue with having a method asDVO on an object to get its DVO representation. However as we all know J2EE and the passing of these objects across the network don't always belong to a specific persistent object. For example (a bad one but bear with me) I have 2 persistent objects Person and ExamResults and want to create a DVO that combines this info - say called 'Foo' as this is the information I want to display on the web tier. My beef is there is no object to call asDVO on to get this object and the pattern breaks down.

    Ta.
    J
    Reply to this Reply to original

  19. Value Objects vs Entity Bean Caching[ Go to top ]

    Hello,

    I would like to see some comparions of ValueObject and the entity bean caching using one of the caching product. I understand that at the moment EB caching products are not free. (Is there a free one or JBOSS planning to support it?)

    Thanks.

    Reply to this Reply to original

  20. Value Objects and Value Object Factory patterns posted[ Go to top ]

    One thing that I don't see any guidelines on is the role of the DTO/VO within a MVC paradigm. If DTO's and VO's are just strict data objects without business methods, then the client must have access to a model that does. Example would be sorting on fields, and selecting sublists from collections, of VO/DTO for the client to display in a view.
    Reply to this Reply to original