tags:

views:

1329

answers:

4

There's a diagram depicting the difference between traditional MVC and Cocoa MVC here:

Cocoa Design Patterns: The Model-View-Controller Design Pattern

Are there any benefits of doing it the "Cocoa" way in .NET using Visual Studio?

+3  A: 

There's no reason not to do it that way, if it makes more sense to you. Be aware that a lot of things in the Cocoa framework are the way they are due to higher-level design decisions, for example favoring composition and delegation over subclassing.

If you want, you can design C# software that looks like Objective-C software, but people with no Cocoa experience will have to have it explained to them, because the loosely-coupled design will just seem "weird" to them.

Oh, right - the advantages of that design include greater re-usability of the UI view and model classes (since they won't have any knowledge of each other), slightly simpler code in the view classes, and more of the "application logic" in a single place (the controller classes).

Mark Bessey
A: 

Isn't the "Cocoa version of MVC" the pattern used in ASP.NET MVC? So far, all the examples have pointed to communication b/w view and model through the controller with no direct interaction between V and M. Am I understanding this incorrectly?

Codewerks
I think they're more-or-less the same (but I'm no ASP.NET expert). A lot of prior "MVC" implementations encouraged tight coupling between models and views, which is what Apple is trying to discourage.
Mark Bessey
A: 

The main advantage to using Cocoa's "Mediating controllers" (subclasses of NSController) is that they implement a large part of the standard functionality required to mediate between a model and its view. Things like tracking the part of the model indicated by the view's selection, and transaction support (so that you can, for example, commit or discard a set of modifications to the view or model) are included, 'for free'. Using the NSController subclasses as the 'glue' code between model and view frees you as a developer to focus your efforts on the "Coordinating controller" functionality—the application-specific logic that resides in the controller layer.

So, is it worth using this pattern in .Net? Getting a general coordinating controller to work correctly is not trivial (it took Apple a couple of releases to get it all right, for example). Things like tree controllers are particularly tricky. If you're only using this pattern in one or a few projects, it might not be worth the effort. On the other hand, I'm sure the community would appreciate a general controller framework ala Cocoa's NSController hierarchy.

Barry Wark
+1  A: 

A developer on the .Net developer's Journal has been writing about his transition and comparing .Net to Cocoa including using the Cocoa MVC style in .Net

http://dotnetaddict.dotnetdevelopersjournal.com/tags/?/cocoa

Jeff Huff