This points to a lack of developer education surrounding architecture and design. Most projects have too few abstractions, and/or a weak domain model. The Internet likes to complain about Java-style over-abstraction, but I've never seen that.
I think devs don't like to think about architecture because it implies they're not doing things well, it is highly subjective, and they don't see the benefits immediately. All of these are poor reasons.
In fact, I've just recently had a junior dev. tell me that in MVC, the view was not allowed to talk to the model, instead it had to be fed pre-digested info by the controller. Hmm...
I think the upper limit of possibilities a View should have interacting with a Model for me is the point where your View and Model map 1:1 and the user is able to update the fields of the Model represented in your View. You might argue that in some cases it's better to just let the View not only read the Model and represent it but also let it change values in the Model or even create a new one.
But the decision to read / save / delete the Model should always be taken by the Controller and never be done directly by the View.
I also like to argue that there could be something between the Controller and the View that handles specific chores like input validation and creation of objects from input fields. You have the opportunity to add Objects to your Storyboards for just that reason.
Cocoa does not use the traditional notion of MVC.
All documented here very clearly
MVC as a Compound Design Pattern: https://developer.apple.com/library/ios/documentation/genera...
"The controller object in this compound design pattern incorporates the Mediator pattern as well as the Strategy pattern; it mediates the flow of data between model and view objects in both directions. Changes in model state are communicated to view objects through the controller objects of an application."
Well, you're supposed to have a different controller for every major view.
And said controller can always delegate to some object model specific to your app.
The model in MVC is the aspect of the real world that's being reflected in the app. This can and should include network communications and business logic. The architectural issues here are that people are mis-using the idea of a model.
Why do models know how to persist themselves? Or send themselves over the network? What does that have to do with the concept they represent? It conflates technical concerns ("how do I serialize myself?") with business concerns ("am I valid?").
It doesn't help that Core Data forces you into the framework superclass antipattern: http://michaelfeathers.typepad.com/michael_feathers_blog/201...
And I guess technically it's MVVCVM.
Xamarin's come out with Xamarin.Forms which looks like it could supersede MvvmCross but I gave it a shot and it's pretty immature right now. Plus its dependency injection leaves a little to be desired [2].
[1] http://www.codeproject.com/Articles/566270/
[2] Out-of-the-box it appears to have a global service locator and no constructor injection.
It might be an unfair comparison as MvX is a much older project but it felt more like something cobbled together over time than something really thought out. I also really like the reactive approach - your view model describes the relationships between its properties as they change rather than have a morass of interlinked event handlers.
Paul Betts is pretty active within the portable-C# community, with multiple active projects: https://github.com/paulcbetts and has a pretty good blog, where at the moment he's going back through the RxUI docs: http://log.paulbetts.org/
Order Summary
Xamarin.Android Business 999 × 3 2997.00
Xamarin.iOS Business 999 × 3 2997.00
$5,994.00
Multiple Licenses 10% –599.40
Total:
$5,394.60The examples that are available on SO, the apple docs, and IB generated/influenced code work great for the simple case but fall down a bit when your app grows. there are much better and simpler ways to handle some of the common patterns in large apps, for example the great thin view controllers article.
Objc.io is a fantastic resource.
Which is generally a good idea, and has lots of benefits, including better testability.
It's another example of how "Model" is a vastly overloaded term, to the point of being almost meaningless. Depending on who's talking, a model is: a database entity representation, a domain logic container, an everything-but-controller-logic holder, a DTO from dao to service, a message from service to controller, a command object from controller to view.
Would have been nice to see the actual implementation / code of the Parallax Scrolling Behavior example[0].
Is there something equivalent for Android?
because that would turn off the readers.
Show me a singleton and I'll show you a doubleton, no wait, its a tripleton....