[ricardobeat]

The common MVC project uses "fat models", where each Model encapsulates it's respective business logic. Then the Controllers simply decide which methods to call from the Model, call other necessary services and manipulate the data to respond with a specific format; what you describe would be a "fat controller/skinny model", or maybe a service layer. You'll end up with some kind of Model either way, data structures will have to be defined somewhere.

I'm conflicted whether dropping the known patterns and established terms for this architecture is a good or bad idea, but it's interesting nonetheless. It's quite hard for a newcomer to grasp and implement MVC correctly, an architecture with clearer nomenclature and concepts might be helpful.

[parallelist]

I don’t see how you have inferred a fat controller and skinny model from my description. In fact I use the terminology of interfacing to describe what others here have interrupted back into MVC terms as a controller. That should be an indication as to the extent of its role i.e. not that large

My action layer is definitely fatter than the usual model because it does all the real work (that which persists) associated with a particular request. You could argue it is equivalent to involving several of the traditional models. I think it might also be fair to state that this represent an absence of architecture in that particular area and I would agree but there is nothing to suggest that you couldn’t create models with the action layer if you felt it was useful. Strictly speaking I’m against that sort of thing until I see a good case in front of me why I should do it. Writing queries is not so bad that I want to put something in front of it to automate it