View/Controller best practices

[Former Member]

Hello,

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?

Thanks,

Jennifer

[Former Member · Accepted solution]

Hi

The Web Dynpro follows the MVC Paradign. Though its a triangular Architecture, yet there are Some Standards to be followed (ie) Whatever comes into the application it must be known to the controller thats why it is named as "Controller" that controls the application. It controlls the Flow of Data between View and the Model.

View <--

---

>Controller <--

---

> Model

The Model is an Independant Component and its just acts as bridge between the application and your backend. The Model can be directly mapped to View ..anyway it is possible but according to me its not the right standards. We should move through Controller is the right standard. The Controller must know whatever comes in to the application.

Regards

Chandran S

[Former Member]

We have had the same discussion at my Company and came to the following conclusion and coding standard. It is preferable to keep all backend model call logic in the Component Controller, for various reasons if you ever drop a view or goto using some other type of UI interface e.g. PDAs, with the same controller you already have the functionality there in the controller coded and tested.

What I have seen happen before we adapted this standard with consultants or less experienced developerrs is that they tend to copy and paste the same functionality from view to new view creating a maintenance headache down the road, even duplicating the code as they can not find the functionality or are too lazy to look for it then try coding their own. It is for this reason our company adapted the best practice of creating all backend call logic even if it is only required by a single view Dynpro View, in the component controller and calling it from the view as <b> wdThis.wdGet.doXXXFunction();</b>

Also this helps code maintainers and new team members as they know all backend call logic is in the controller. I believe you will also find this practice recommended in the SAP Press WebDynpro Java books.

Alex