21–30 of 233 posts
Seems like a reasonable way to structure an application. It would be great to see a concrete example or two. The login example that is sketched out gets you partway there.
Do you haz teh codez?
The idea in practice gives a much better idea of what the pros and cons are.
You know it's nice reading a criticism of something that has an alternative solution offered rather than just going "hey MVC is terrible and you're an idiot for using it". I do however think there's still great benefits to MVC, if you're shovelling code into controllers and can't make it work like it should then MVC is not the right design pattern for the project. Like every other pattern it'll only work when it work…
The MVC abstraction has an issue with web applications, since the request-response cycle doesn't provide feedback as directly as the hardware-monitor-software cycle that the pattern was originally designed around.
However, if the problem is that you are putting too much "logic" into your controllers, you should probably find a better place for it.
In Java/Spring-MVC, there is a typical class hierarchy of Controller -> Manager/Service -> DAO. The extra level of indirection is a very handy place to put business logic, then each class in the tier has a dedicated function:
Controller -- Parses input, delegates the action and returns the response (rendered by the view).
Manager -- Handles sanitized data, encapsulates business logic and makes calls into the Model / Data layer.
DAO -- Interfaces with the data store, makes sure only good data goes in, and appropriate responses are returned.
It seems like this problem has arisen from a rather narrow reading of what an MVC system should be, as in, not having utility libraries because they aren't strictly an M a V or a C.
*edit: formatting.
And Events are handled with a combination of Key-Value Observing and UI binding. http://developer.apple.com/library/mac/#documentation/Cocoa/...
Controllers still exist but the design of a program is easier to reason about if everything that mutates data is pulled out of the controller.
UI changes must be made on the main queue, but the above design helps pull out model changes, network requests, etc on to background queues.
I prefer the term "Services" over "Operations". Services is where the logic of your application should live, and services should be HTTP (or any protocol) agnostic. They should only speak in models and native types, and should abstract all of your logic away from your controllers and models. This leaves the controllers as a thin http handling layer that parses inputs and then lets the service handle the work. The res…
This looks like a really good way to stop putting all your messy code into Controllers and start putting it into Operations. The problem with messy code or where it lives will not go away because you think about it differently, you just have to either hire better people or spend more time and money refactoring.
The advantage of operations over controllers is the composability. Whereas controllers have a pretty undefined lifetime, operations are finished when they're done. This means that operations can use each other to get work done, a pattern you don't see with controllers.
Earlier quoted context omitted.
I think the problem with most MVC frameworks is not the framework themselves, but that that the MVC design pattern should only be considered while refactoring existing working code. Starting right off the bat with a giant MVC boilerplate isn't necessary and may even be counter-productive. I write my code initially as one monolithic controller, and then refactor my code into an MVC pattern. It doesn't take that long t…
So this could be the part where I'm not that great a programmer, but the I've had trouble creating apps from scratch with MVC, not just refactoring existing code.