Extending a proxy

[albertkang75]

I would like to extend a Proxy that is calling a webservice; however, I'm not sure if this is advisable.  The scenario is I have 2 webservices that expose the same webmethods; however, they have different return types, i.e. the first service might have methods that return a type "Cat" and the other service have methods that return a type "Striped Cat". 

i.e.
catservice.asmx
getCat():Cat
getOldCats():Cat

stripedCatService.asmx
getCat():StripedCat
getOldCats():StripedCat

Would I have to recreate the exact same proxy twice?

[dihardja]

Hi,

in projects, i often have multiple proxies extending one base proxy. inside the baseproxy i usualy put the authentification values for the webservice, the base url of the service, error handling, etc. in the derived proxies then, the specific task. for example a proxy for user login, a proxy for registration, a proxy for saving specific settings, a proxy for searching etc. in my opinion, it is more maintainable having multiple proxies rather than handling all the conditions iniside one big proxy.

[albertkang75]

i have no desire to have one big proxy - what i would like is to have one proxy subclass another proxy but send out different notifications with different payloads/bodies (i.e. Cat vs. StripedCat).

[dihardja]

i see, sorry to missunderstand you. just curious, without knowing the context of your application, is it possible then to have one proxy with the following methods:

getCat():Cat
getOldCats():Cat
getStripedCat():StripedCat
getOldStripedCats():StripedCat

because of the same method names, i assume that the usage of objects of type Cat and StripedCat are in the same context. therefore my opinion is to let one proxy ( e.g. the Cat proxy ) get the data even if more than one service call is required. after the data is ready, the proxy can notify it and can be used by the rest of the system. 

[albertkang75]

that's the scenario i'm trying to avoid - writing more code that could ideally be avoided by just extending another class.

[dihardja]

extended or not extended, one proxy is one proxy.

[albertkang75]

copy and pasting over and over to make a bloated class is definitely not ideal.

[dihardja]

well, one proxy is not the same with one bloated copy paste class. at the first point it means one data interface for a specific context in the application. how the proxy handles and manage to get and store the data internally is up to the developer. is it by extending another proxy, having references to other data objects etc. my thought with this is refering only to the lines of code in your post. therefore, it is of course possible that other constructs may fit better if other parts in the application are considered.

[puremvc]

in projects, i often have multiple proxies extending one base proxy. inside the baseproxy i usualy put the authentification values for the webservice, the base url of the service, error handling, etc. in the derived proxies then, the specific task. for example a proxy for user login, a proxy for registration, a proxy for saving specific settings, a proxy for searching etc. in my opinion, it is more maintainable having multiple proxies rather than handling all the conditions iniside one big proxy.

I don't see the problem with the solution as described in dihardja's first response. The suggestion is not to make one big proxy but instead to extend a base proxy with multiple subclasses. There's no cut/paste/bloat there.

-=Cliff>