Bronze Challenge and MVC


#1

It seems like the MVC for TouchTracker is wrong. The view is interfacing directly with the model, and the controller isn’t doing much of anything. I understand this is a simple app, but I’ve always struggled with how to properly implement MVC with drawing code.

I created a BNRGeometryStorage class that stores the linesInProgress and finishedLines. This class will archive/unarchive the data. My question is shouldn’t the BNRDrawViewController be doing most of the work here (i.e. passing the data from storage to the BNRDrawView and creating new BNRLines to add to the BNRGeometryStorage as touch events come in)? I’m not sure what the proper pattern is though. Should the BNRDrawView event handling calls (e.g. touchesBegan:withEvent: call methods on BNRDrawViewController? Or should this use the Notification Pattern–where these events create notifications that the BNRDrawViewController responds to (i.e. so the view is loosely coupled from it’s controller).

If one were to implement this challenge using “proper” MVC patterns, how would the classes interact?


#2

If you are working on your own, use MVC as a theoretical guiding principle, deviating from it whenever you feel necessary to reduce the amount of code, usually for performance gains. (This is probably the approach taken by the book.)

However, there are a few classes of problems that benefit enormously from applying MVC to its theoretical limits.


#3

If you are working on your own, use MVC as a theoretical guiding principle, deviating from it whenever you feel necessary to reduce the amount of code, usually for performance gains. (This is probably the approach taken by the book.)

However, there are a few classes of problems that benefit enormously from applying MVC to its theoretical limits.[/quote]
Thanks for the response. Just as an academic exercise, how would you refactor the classes so they strictly conform to MVC, loose coupling, etc.? I realize the book’s implementation is a lot more practical for keeping the code small (which is important for a printed book), and would have performance benefits without having to pass calls back and forth between models and views via a controller. The problem is that if one were to extrapolate this simple app into something much larger and more involved, I don’t think it would be a good template to expand from. The BNRDrawView could easily degenerate into a God class.


#4

You are correct; implementing the example in the book with MVC would be an overkill and would also take more room in the book.

However, I can give one concrete example which will benefit from MVC. Imagine an application which allows one to enter a number and to display it simultaneously in four different number bases: base 2, base 8, base 10, and base 16. One could implement such an application with these components: four instances of a number view for accepting a string as input and displaying it, four view specific controllers, and a master controller (plus, maybe, four tiny model objects.)

Also as an academic exercise, one could implement the example in the book with two components: a view for both drawing and reporting the touches, and a controller acting as the view’s delegate. The view would report the locations of the touches to its delegate, the controller, which would then instruct the view what to do.


#5

Again, thanks for the reply. The BNRDrawViewController class is in the responder chain, so it will receive the event calls if the view doesn’t override them. I stripped out the event handling code from the BNRDrawView Class and moved it to the BNRDrawViewController. This Class instantiates the BNRGeometryStorage class (which I’m also using for the gold challenge) and is responsible for archiving/unarchiving a NSMutableArray of BNRLine and BNRCircle objects. The BNRDrawView is now limited to just drawing code which seems more appropriate.