What I find here (now that you explained it in more detail) is that you have simply factored out some objects: strongly related sets of values that make sense to package up and send to the server as a single object. I think of these as Model objects of a sort. They are not all that different from model objects that travel in the other direction, sent from the client to the server.

So there’s nothing especially exotic going on here, other than the fact that you call these factored-out objects “parameters” and make them 1-to-1 with the set of operations. Such refactoring is a natural way to simplify any complex API with recurring subsets of parameters. I think if you focus on just rolling up the values that always occur together into named classes, rather than always having a single XYZParameters subclass for each XYZOperation, you’ll have a more natural and intuitive Service interface. At that point, one might name than “XYZInfo” objects or something of that nature.

Can you help??

(For reference, I am trying to put ReviewTube components into MDI windows like those used by Christophe Coenraets.)

public class OperationParams{
private var username:String = Config.instance.currentSession.currentUser.Username;

// Username
public function get Username():String{
return this.username;
}

public function set Username(v:String):void{
this.username = v;
}
}

(I’m using getter/setters because they can be overridden by a subclass if need be.) This way, any time a Parameter object is instantiated, it is automatically prepopulated with those common values. The Parameter object is actually instantiated in the Controller, populated with the remaining (non-common) values, and passed into the Service method (which passes it into the operation it returns).

This doesn’t feel right because I came up with it myself, as opposed to implementing a known good interaction pattern. Is there something I’m misunderstanding in your MVCS architecture that would make the need for Parameter objects irrelevant? Or is there another interaction pattern that you feel would better serve the purpose?

Thanks again for your indulgence.

Thanks for the great comments.

(I also took a look at your blog and responded to a much earlier comment you made about the question of why there isn’t a unitary Model object somewhere. Briefly, the answer is — there certainly can be such an object and in many cases it’s a good idea, but for the particular case of ReviewTube it doesn’t seem to make sense to me.)

1/ About the Parameter objects, I assume those are internal to the Service/Operation part of the architecture and don’t make it into the Service interface that the rest of the app calls. If they are indeed internal, then it sounds like a fine solution to your problem — presumably you have various stock parameters for your HTTP requests and this gives you a way to encapsulate their structure. If they are exposed as a public data type, then the app developer has to pass a FooBarParameter object into each Service method, which seems like a big nuisance if the parameter is just a String, an int, or whatever.

2/ Questions about ViewStates and things like them come up a lot because they fall into a gray area. When is a ViewState a separate model-like object and not just some property of some view somewhere? My feeling is that a persistent ViewState is a perfectly legitimate *kind* of model, but not the same model-with-a-capital-M that represents the semantic data for the application. The fact that it gets persisted is a very good argument for separating it from the actual view components themselves. I certainly would want to keep ViewStates in a separate object, possibly living in the Controller (since the controller presumably plays some role in applying these states to the view).

Hope this helps!

First, I found it useful to create a set of Parameter objects to be passed into the Operations – this way, each parameter is strongly typed, and it is this parameter object which is passed through the Service object, into the Operation (simplifying the method signatures). The Parameter objects all inherit from the same base class, which has a toSimpleObject method which returns an object containing name/value pairs (HTTPService requires a simple object – strongly typed objects won’t work). In my case, each web service call required around 10 parameters, so changes in the web services became more difficult to manage. If the parameters of a web service changed, I had to update them in the service interface, the service object, and the operation object. With a Parameter object, the changes are in one location only. Now to decide where to put the darn things – do they belong in the Services packages, the Operations package, or are they more properly part of the Model?

Secondly, I’m thinking a “ViewState” object would be a useful addition to the architecture. It would store any view object’s properties that you might wish to save for later restoration, but that don’t really belong in the model. For example, you might have a preferences PopUp dialog with some comboboxes whose selected indexes you’d like to persist each time the PopUp is shown. For some reason it doesn’t feel right to put those kinds of things in the Model, but maybe that’s exactly where they belong…? Care to comment?

Thanks a lot for your article. It has taken me a giant step forward!