Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

iOS application architecture: MVVM, behaviors, singletons, subclassing

objc.io

Post reply on HN
Print view View original

11–20 of 36 posts

Re: iOS application architecture: MVVM, behaviors, singletons, subclassing

#11

Post by Glide »

AshFurrow wrote: post #8
tangozulu wrote: post #5

The MVVM and other ideas in the issue are, at the core, about broadening what the definition of "model" means in an app. The authors seem to think "model" currently is just the data store of an app. But that's never been correct. 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 t…

Hi there – I wrote the MVVM article, and I see your point. There is a line to be drawn somewhere, but that's often up to the developer. However, on iOS, models tend to be very thin, through convention (typically, they're only a Core Data "managed object" and have no logic at all in them). I hope that helps clarify where the article is coming from.

Hmm... If I may say so I find that the MVVM pattern in iOS to be very cumbersome when compared to how it can be done in WPF. You essentially need another layer of indirection in iOS where you need none in WPF. That's probably why I personally haven't heard about it before in CocoaTouch land.

And I guess technically it's MVVCVM.

Re: iOS application architecture: MVVM, behaviors, singletons, subclassing

#12

Post by 21echoes »

mpweiher wrote: post #10
mattgreenrocks wrote: post #6

It is interesting that iOS apps suffer the same sort of runaway complexity that often plagues Rails apps, whereby the controller absorbs too much responsibility and becomes unmanageable. This is usually the collateral damage of an app growing within the overly tight conceptual confines of model/controller. This points to a lack of developer education surrounding architecture and design. Most projects have too few abs…

The problem, as with rails, is that the frameworks, documentation etc. encourage this. That's how you make the cool "look ma, no code" demos work: thin model ("ideally" just a CoreData object drawn in the modeler), UI painted in IB, controller to hook it all together. But it's less than ideal, er, for non-trivial programs. In fact, I've just recently had a junior dev. tell me that in MVC, the view was not allowed to…

and you'll also notice that the linked article says the same thing (that the model and view never touch each other but instead communicate through the controller)... I've always learned MVC as strict separation of model and view, but I've recently heard more and more people saying that they think they should talk.

Re: iOS application architecture: MVVM, behaviors, singletons, subclassing

#13

Post by tunesmith »

Skimming the MVVM article from a web programmer perspective is really interesting because it is conceptually the same thing as introducing a "service" layer between your controller layer and your dao/repository layer.

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.

Re: iOS application architecture: MVVM, behaviors, singletons, subclassing

#14

Post by dep_b »

21echoes wrote: post #12
mpweiher wrote: post #10

Earlier quoted context omitted.

The problem, as with rails, is that the frameworks, documentation etc. encourage this. That's how you make the cool "look ma, no code" demos work: thin model ("ideally" just a CoreData object drawn in the modeler), UI painted in IB, controller to hook it all together. But it's less than ideal, er, for non-trivial programs. In fact, I've just recently had a junior dev. tell me that in MVC, the view was not allowed to…

and you'll also notice that the linked article says the same thing (that the model and view never touch each other but instead communicate through the controller)... I've always learned MVC as strict separation of model and view, but I've recently heard more and more people saying that they think they should talk.

There's no silver bullet method.

If you do MVVM on an app that is sparse on input controls or text labels it's overkill. MVVM shines where you have a lot of data going back and forth in screens combined from different models and you want to be able to test everything you see.

If you are doing an app that is much more graphical in nature and the models that feed it are not really mapping to databases or web services they gel much more natural with your UI and mixing them up with each other is no problem at all.

I enjoyed MVVM a lot in WPF especially because of the two-way binding it provided. That was in an application that managed health care records so it was very text heavy and a lot of screens were taking context from Models left and right.

We went with full MVVM for complex screens and direct Model mapping when we had a screen where you would edit just a support table, like a list of doctors or treatment types.

Re: iOS application architecture: MVVM, behaviors, singletons, subclassing

#15

Post by UK-AL »

21echoes wrote: post #12
mpweiher wrote: post #10

Earlier quoted context omitted.

The problem, as with rails, is that the frameworks, documentation etc. encourage this. That's how you make the cool "look ma, no code" demos work: thin model ("ideally" just a CoreData object drawn in the modeler), UI painted in IB, controller to hook it all together. But it's less than ideal, er, for non-trivial programs. In fact, I've just recently had a junior dev. tell me that in MVC, the view was not allowed to…

and you'll also notice that the linked article says the same thing (that the model and view never touch each other but instead communicate through the controller)... I've always learned MVC as strict separation of model and view, but I've recently heard more and more people saying that they think they should talk.

Traditionally(on desktop applications) the model was injected into the view, then actions(save, delete, buttons etc) were performed on the controller.

However the way Apples IBOutlet system works, makes this difficult. You link up the UI to fields on the controller.

The first significantly reduces code size.

Re: iOS application architecture: MVVM, behaviors, singletons, subclassing

#16

Post by dep_b »

mpweiher wrote: post #10
mattgreenrocks wrote: post #6

It is interesting that iOS apps suffer the same sort of runaway complexity that often plagues Rails apps, whereby the controller absorbs too much responsibility and becomes unmanageable. This is usually the collateral damage of an app growing within the overly tight conceptual confines of model/controller. This points to a lack of developer education surrounding architecture and design. Most projects have too few abs…

The problem, as with rails, is that the frameworks, documentation etc. encourage this. That's how you make the cool "look ma, no code" demos work: thin model ("ideally" just a CoreData object drawn in the modeler), UI painted in IB, controller to hook it all together. But it's less than ideal, er, for non-trivial programs. In fact, I've just recently had a junior dev. tell me that in MVC, the view was not allowed to…

I think your junior dev shows some promise. Maybe too orthodox in his thinking or taking wrong conclusions from the right info, but at least a hopeful glimmer of understanding.

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.

Re: iOS application architecture: MVVM, behaviors, singletons, subclassing

#17

Post by ktran03 »

mpweiher wrote: post #10
mattgreenrocks wrote: post #6

It is interesting that iOS apps suffer the same sort of runaway complexity that often plagues Rails apps, whereby the controller absorbs too much responsibility and becomes unmanageable. This is usually the collateral damage of an app growing within the overly tight conceptual confines of model/controller. This points to a lack of developer education surrounding architecture and design. Most projects have too few abs…

The problem, as with rails, is that the frameworks, documentation etc. encourage this. That's how you make the cool "look ma, no code" demos work: thin model ("ideally" just a CoreData object drawn in the modeler), UI painted in IB, controller to hook it all together. But it's less than ideal, er, for non-trivial programs. In fact, I've just recently had a junior dev. tell me that in MVC, the view was not allowed to…

You are thinking of the traditional conception of MVC, where the model notifies the views of updates and changes (i.e. they can talk to each other)

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."

Re: iOS application architecture: MVVM, behaviors, singletons, subclassing

#18

Post by coldtea »

mattgreenrocks wrote: post #6

It is interesting that iOS apps suffer the same sort of runaway complexity that often plagues Rails apps, whereby the controller absorbs too much responsibility and becomes unmanageable. This is usually the collateral damage of an app growing within the overly tight conceptual confines of model/controller. This points to a lack of developer education surrounding architecture and design. Most projects have too few abs…

>This is usually the collateral damage of an app growing within the overly tight conceptual confines of model/controller.

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.

Re: iOS application architecture: MVVM, behaviors, singletons, subclassing

#19

Post by taspeotis »

If you're enamoured with MVVM and know C# you might consider trying out Xamarin + MvvmCross [1]. I'm using it on a few projects and the code shared across platforms is (ballpark) 70-90% depending on the size of the project.

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.

Re: iOS application architecture: MVVM, behaviors, singletons, subclassing

#20

Post by mariodiana »

ktran03 wrote: post #17
mpweiher wrote: post #10

Earlier quoted context omitted.

The problem, as with rails, is that the frameworks, documentation etc. encourage this. That's how you make the cool "look ma, no code" demos work: thin model ("ideally" just a CoreData object drawn in the modeler), UI painted in IB, controller to hook it all together. But it's less than ideal, er, for non-trivial programs. In fact, I've just recently had a junior dev. tell me that in MVC, the view was not allowed to…

You are thinking of the traditional conception of MVC, where the model notifies the views of updates and changes (i.e. they can talk to each other) 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…

There's something else to architecting a Cocoa app that I want to add, mainly because I had heard this a while ago but only just recently figured out how to incorporate it. There are Cocoa programmers (my understanding is that it is mainly the O.G.'s) that make good use of class extensions and categories to split the functionality of a class into different source files.

For example, if you have a view controller handling a table view that makes use of many delegate and datasource methods, it's easy to have code spilling all over the place. But you can use extensions and categories to separate out the delegate functionality into its own set of files, and do the same for the datasource as well. If you share the header files among the files, then to the computer it all works like one big class. But to the programmer -- and this is the whole point -- the functionality is broken out into conceptual units.

What you end up with is still a "god class," but instead of being monolithic, you wind up with a god of many faces. (I'm whimsically calling it the "Brahma" pattern.) Anyway, I suggest people give it a try if they've been having trouble organizing their code.

Does anyone on here have experience organizing their Cocoa apps this way? I'd be interested in hearing your input, since I've just gotten around to looking into this myself.

Post reply on HN