View/Controller best practices
A coworker and I are in charge of creating the standards for Web Dynpro development at our company. We've been able to agree on most topics, but we're stuck on one issue. Should ALL logic be in the controller or is it ok to perform some logic in the views?
My coworker makes some valid points - we work in a team environment and you can't have two people working on the controller at the same time, if all your logic is in there, it's practically impossible for a group of developers to work on the same application. In addition, there's often logic that's only applicable to a certain view. He doesn't like the idea of a controller cluttered with logic from all the views, and doesn't see why we need to add an extra layer to execute something. For instance, of a model is needed only for one view (say, to look up fields for a dropdown that only exists on that view), why have yet another executeSomeRFC method in the controller when we can do it in the view?
My opinion is that Web Dynpro follows the MVC paradigm, and therefore all logic should be in the controller. While it's true that right now a certain model or a certain piece of logic might only be needed for the one view, you never know if it will be needed somewhere else later. In addition, to make the statement that "logic that's only needed for one view can be done in that view" leaves it open for a lot of interpretation and I think developers can start sneaking more and more code into the view because they think it's easier, when that is not what the view was created for. The exceptions, for me is logic that specifically has to do with the UI - for instance, if you select this checkbox, it will make 4 fields on the table disabled and change the label text of another field.
We both see the other person's point of view and we can't decide where to move from here. We're open to the opinions of other Web Dynpro experts. What do you guys think?