Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: Server query data Proxies best practice  (Read 3315 times)
jpwrunyan
Sr. Member
****
Posts: 84


View Profile WWW Email
« on: January 12, 2010, 06:31:32 »

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!
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: January 13, 2010, 12:48:56 »


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>
Logged
Pages: [1]
Print