"oleksa borodie" <oleksa.borodie@gmail.com> wrote in message
news:1132933562.797660.178590@g44g2000cwa.googlegroups.com...
> Hello
>
> As usually described Application Server (AS) communicates with GUI
> client by Business objects. So client should know about some interfaces
> that is implemented by business objects and some business service
> classes. When some changes occurs in business object interface all
> client module should be updated and redistributed.
>
> Is there any well-known practice to make clients more independent from
> business objects interface? May be exchange between client and AS with
> should be done with simple types and only on the AS side business
> object will be created and its properties will be filled with simple
> types gathered from client?
>
> Thank you.
>

> I think, as a part of initial design, the interfaces/contracts are laid out
> and are not expected to change. However, as we all know, this is far from
> reality. Some of the measures you can adopt are
> 1. Instead of breaking the clients by an interface change, you can implement
> a new interface instead, which newer clients will use, while the older
> clients use the older interface.

> 2. As you indicated, you can use strings (an XML payload) to exchange
> information. You can add any new element without breaking the client (at
> least on the interface). But, make sure you use a different namespace
> (denoting the right version) on the newly added element to ensure it does
> not break client's xml parsing logic.

"oleksa" <oleksa.borodie@gmail.com> wrote in message
news:1133172901.457481.258210@g49g2000cwa.googlegroups.com...
> Hello Manoj!
>
>> I think, as a part of initial design, the interfaces/contracts are laid
>> out
>> and are not expected to change. However, as we all know, this is far from
>> reality. Some of the measures you can adopt are
>> 1. Instead of breaking the clients by an interface change, you can
>> implement
>> a new interface instead, which newer clients will use, while the older
>> clients use the older interface.
>
> Nice idea but works only if some metadata was added to definition.
>
>> 2. As you indicated, you can use strings (an XML payload) to exchange
>> information. You can add any new element without breaking the client (at
>> least on the interface). But, make sure you use a different namespace
>> (denoting the right version) on the newly added element to ensure it does
>> not break client's xml parsing logic.
>
> You mean that something like DTO should be used? The main problem in
> such case is validation on the server side. Take a look please how I
> understand it:
> 0) client ask server to create new object some wellknown type.
> 1) BO created on the server
> 2) BO is converted to DTO and passed to the client
> 3) DTO is displayed and some properties is filled by user.
> 4) while filling properties DTO GUI client should call some validation
> methods that will validate object or compute some value. So DTO should
> be passed to server than converted to BO, validated and passed back.
> It's is too complicated I think.
> 5) DTO data is validated so user is allowed to press OK and finally
> DTO converted to BO and passed to the AS, where will be saved to the
> database.
>
> So the problem is that client should know everything about BO to make
> validation as easy as possible and should don't know anything about BO
> to make it more independent from BO interface. Is there any good
> pattern that will allow break the problem?
>

> the client does
> one pass - basic validation, applying general rules based on fields. For
> example, if the field is a date, it must be a legal date. The server does
> more rigorous validation - does the account start date fall after the
> accountholder's burthdate