Server query data Proxies best practice

[jpwrunyan]

Hi, I'd like to ask the community yet another question about Proxy models and the best practice.

Currently, I have a Proxy that gets its data from the server based on a search condition.  The search condition exists as a single property on the Proxy and is dynamically set by the view (Mediator).

Now, in a simple situation, like an application that searches for a person in the database by a unique ID, I think this would be fine.

But in a complex situation, where maybe the data is being queried by conditions filled out on a form, I wonder if the search condition should be encapsulated by its own Proxy (or VO).

So I'd like to get an opinion about best practice here.  In my case, I will implement the same approach for all situations.

I am thinking about 3 possible approaches:

1) all dynamic search properties will be stored on the Proxy class that requests and stores the search result from the server.  Merit: less class files  Demerit: possibly verbose Proxy

2) all dynamic search properties will be stored on the Proxy class in a VO property for that class.  Merit: simple and standard Proxy  Demerit: more class files, slight overkill for simple situations

3) all dynamic search properties will be stored on a separate search condition Proxy class.  Merit: same as 2, but this just "feels" like a better model structure...  Demerit:  same as 2

Even if you don't have an opinion about which is the best, if you can think of any merits/demerits I haven't, please let me know.
Thanks for any feedback!

[puremvc]

2) all dynamic search properties will be stored on the Proxy class in a VO property for that class.  Merit: simple and standard Proxy  Demerit: more class files, slight overkill for simple situations

This is the right answer. The details of the search conditions are something passed between the model and the view, and belong together as a group. You need to be able to pass them in a single call, and you don't want the mediator getting and setting scads of props on the view component.

Optimally, you show and set the search conditions on the form, click a button and the mediator tosses the SearchVO ball to the model side of the fence where the proxy takes them and sends them off as the single parameter to a remote search method.

So the only actors that need to know the details of the search conditions are the form, the search vo and the service that consumes it. No need for a mediator, command or proxy to know about those details if you can shield them from it.

-=Cliff>