your model should store the state of your application, services
are responsible for fetching/sending data which may also be stored
in a model. You can combine the two but keeping them separate
should in theory make for less confusing code (your model dealing
purely with manipulating data without having to worry about how and
where it comes from), and also allow you to swap out different
services without having to touch your model. A service may well
also be used by multiple models so again, separating out the
responsibilities gives you far more flexibility.
However my issue is not really that I'm trying to put everything
in the service, it's more that I feel like I don't need the model
at all whether it's merged in the service or seperated.
I'm using ampfphp, this means that the data that I receive from
my service is already an instanciated VO. This VO represents in a
way my model and I can transfer it to my view without the need of a
Model class in between. At least that's how it feels in this
I instinctively agree with Matt - and from a 'testing' and 'knowing the state of the world' point of view, models are useful - not least because for most of us they feel like a better fit with our brain's understanding of the app.
However - there are many styles of programming that are essentially 'stateless' - in which you would take the approach you're floating, where the values get passed along to the interested parties without being stored in a model along the way.
The two approaches each have merits.
In fact, we frequently skip the model when dispatching results from services - any message about progress, errors and so on is likely to be sent right from the service out to the view or logger without being stored in a model.
On the other hand, data that might want to be restored, have undo or history, be retained for checking whether there are actually changes to save, be used for logic or flow, and so on, clearly needs a model.
I think the question you're really asking is "in the context of my app, is this a model, or is it just a message?". Your model still exists - it's just outside of the app, sitting on a server somewhere. You've abstracted the M layer of your MVCS entirely into the backend. That's ok - it's just as valid as when we abstract any other layer.
The AWESOME thing about Robotlegs is that you can develop *without* the model, and then, if you find that you *do* need a model, you can just add a command that also picks up the values and stores them in a model. Changing your model / no model decision with Robotlegs should be trivial.
So - high fives to MVCS for allowing a layer to be included / removed within one technical domain as required.
Thank you Stray. That's exactly the kind of answer I needed
I love the fact that I can use models only when I need them. I
just hope that I will be able to tell my self "hey here I need a
model it feels right!". But you gave a few examples giving me a
rough idea so I should be alright.