Depends how you've mapped your domain objects. For example, instead of populating your domain object, you could just populate your complex object. And in some cases - such as hibernate -  you're going to run into lazy issues as you can't transfer those objects across jvm's. So in the latter case you mostly need to seperate the  domain  and complex  objects anyways.

In practice at least for me, the advantages of seperations of concerns have outweighed the tedious gets and sets between your domain and complex objects. This has been especially true in web services work, where there is often more ways than one to get and use the data.

Now if your domain objects were xml or could be mapped as xml easily via frameworks such as hyperjaxb, it could open up your options.

Just my 2 cents.

HTH,
Robert
http://www.braziloutsource.com/

On 5/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Hi,

I'm struggling a bit with the following.

Say, I have a web service that allows you to search for customers. It accepts a customer name, and returns a set (any number) of customers. The response xml may look like

<customerSearchResponse>
        <customer>
                <number>123</number>
                <name>John Doe</name>
        </customer>
        <customer>
                <number>987</number>
                <name>Jane Doe</name>        
        </customer>
</customerSearchResponse>

Obviously, in my application I have a Customer class. Now if I create a wsdl for this web service, and generate the server side code for it, one of the classes that is generated is a customer class, that represents the customer in the xml response. On the other hand, I have the Customer domain object, which is a different one. To generate the response, I have to create 'xml response' customers, and basically copy the information from the Customer class to it. The above example is very simple, but you can imagine more complexe cases that would involve a lot of copying from domain objects to xml representation objects. This is very tedious and error-prone work -- typically work that I would like to avoid.

Is there an elegant way to solve this issue?


Thanks,
Tom

Reply via email to