Here’s an excerpt from a book I’m reading about application design with MVC:
Ideally, the view is so simple and
logic-free as to need virtually no
testing. Users (and developers before
users) can reasonably test the view by
simply looking at the pixels on the
screen. Anything else beyond pure
graphical rendering should ideally be
taken out of the view and placed in
the controller and model. This
includes, for example, the logic that
determines whether a certain button
should be enabled or grayed out at
some point.
what does the bold statement mean to you? what would this look like?
thanks,
rod.
The logic that decides when to enable or disable the button should be residing in the controller and simply calls a method e.g view.EnableContinueButton() to enable/disable the button on the page.
The actual code to enable/disable the button on the page itself should be implemented in the view e.g a EnableContinueButton() method then which calls something like btnContinue.Enable().
Simply put, the view should concern itself with the UI details (show/hide/enable/disable UI elements) and leave all business logic processing to the controller. In this way, the controller does not need to concern itself with the UI elements and the view works independently of the actual business logic.
e.g in the Controller,
and in the View
Frankly I haven’t got much experience in MVC (implemented in one project a while back) but I hope the logic separation between controller and view is clear enough.