Another quickie post, as I spend more time on my Mac Mini and tinker
with Xcode, it's really starting to sink in that all this talk lately over the last few years
about MVC (Model-View-Controller) is really heavily themed in the entire workflow and almost mandatory software architecture patterns in the OS X environment.
You've got Objective-C forcing you to declare your controllers and objects in a very loose fashion, managing everything with delegates and interfaces.
You have Interface Builder forcing you to build out your views with zero application logic but with hooks everywhere. (This unlike the code-behind model in Visual Studio for all views.)
Then
on the data side you have Core Data,
http://developer.apple.com/macosx/coredata.html, which really goes a
long way to facilitating MVC relationships with the views in Interface
Builder and with the general flow of the application.
In some
ways, I'm reminded of the amount of effort Microsoft has gone through
in Visual Studio to support data binding, except there's an incredibly
beautiful simplicity yet sophistication about Apple's approach, where you don't just data
bind to inject data into a view, as in dumping data, rather you provide the data models and the controllers to
handle the delegates and the actions of the view. The implications of
these differences can be staggering. And I know that Visual Studio/.NET facilitate delegation for these things (raising events), but the approach is just not as MVC-oriented. Visual Studio doesn't enforce MVC, Xcode/IB does. Visual Studio allows for MVC, that is, but Xcode/IB imposes it--or at least makes it really obvious that it's the best way to work in Xcode.
Which one is better? Neither; Visual Studio offers versatility whereas Xcode/IB offers elegance and predictability. I love them both.
Subscribe