Simple (maybe) MVC question.
I am wrestling with the application of the MVC concept in Web Dynpro.
Take for example a component that houses a generic CRUD. I might create within the the component 4 windows; one for create, read, update and display each. I also create the respective applications. Assume I want to point Portal iViews to those applications.
Now, here's where I am not clear on the best method. Considering a particular app will only load the appropriate window, lets use create for example, it makes sense to capture all of the logic for create independently of any other (such as update for instance) logic. I'd like to obey the MVC principles but seem to be getting mixed signals from the research I have done.
My question boils down to this: given the above scenerio, would, for instance, the create logic that access back-end services (model) be housed in a custom controller (built just for create functionality) or do I put all that logic into the actual create view controller instead?
Thomas Jung replied
There is no definitive right or wrong answer here. Following MVC is less than a perfect sceince. The main point is to strive to encapsultate reusable parts of your application.
That said, I'm not sure that I would break my application down into different windows or components for Change/Create/Display. Each of these different "views" on the same application have far too much in common.
I would study the Object Instance Floorplan for Web Dynpro ABAP. It is designed for typical CRUD operations. Generally there is an initial screen that lets the user choose between create/change/display as opposed to the old way of having separate transaction codes. Then you break down the business object into separate components logically - one for headers, one for items, etc. If you want I can send you some screen shots of a sample application and of the new Web Dynpro ABAP version of order entry. Contact me - my contact info is listed in my SDN business card.