On Jul 10, 2008, at 11:33 AM, oscar.12321 wrote:
I seems to me that commands are not user gestures, nor clicks or backend queries. The only posible explanation to me is as use cases are abstract (What kind of things can the the user do?) so there is no a fixed rule.
In my experience, use cases are more appropriately tied to events, not commands.
In essence a methodology to identify commands could be: 1. Try to hold the view state in the view.
Yea, but that's not necessarily always the case. Consider the states Logged in/out. Those two states are application level and are something that typically would be stored in the application model locator.
Remember, state can be global (application) or micro (mini mvc, or mv only). You might have a portion of your application that works on, say, a selected item, such as selecting an item and modifying it's properties before adding it to a cart. This situation doesn't need a selected item in the main application model.
There are applications that, for example, might be geared toward working on a collection of elements and all views and portions of the application need to bind to that (not a storefront-type app).
Let's say you write an image editing application. The selected image that is being edited would be stored in the application model because everything in the application aside from selecting the image to edit performs operations on this selected image.
Here you'd have the global 'selectedImage' property in the model that views bind to, but then the view collections themselves may have a local copy of that to work on (for undo/redo functionality, for example).
2. Determine the use cases, and make a command for each one.
Not all the time. Some use cases are such that they kick off a chain of events. For sake of argument, let's say 'addToCartEvent' has three other events that need to occur before the final 'addToCartCommand" is executed. Lots of things can happen in a use case life cycle.
3. Any backend query is also a command.
Not necessarily either. It may be a single command with a collection of delegates.
4. If you need to update the model from the view, don't do it directly. You have discovered a new command an probably a use case.
That I do agree with. I never have my views modify the model directly. That's generally frowned upon (though I'm sure there are limited situations where this might be beneficial).
just my 0.02. good luck with your experimentations with the framework. cheers, jon
