Pages, Views and Popups - Data Flows
I think i have written a few posts on popups and the issues with layer development before. Today, I was encountered with another classical situation involving Pages, views and pop-ups. And for a change i was invited to be a part of the debate. The scenario was as follows: We had a page, which was in all essence a master page dealing with the background service. This page fundamentally had a tab control with every tab's container having its own control. Now each of these controls led out to one or more popups (again effectively more controls). The issue was to treat the controls as controls and try to relinquish them of all Svc calls. Mind you at this stage no calls were being made from any of the controls but we just wanted to come up with a solution where in we could once and for all decide a standard protocol by which we could completely avert situations involving svc calls being made from the controls.
After a good length of discussion we got to the following structure:
Svc <> Page <> View Mode control <> Edit Mode Popup
The idea was to manage data flows in this simple scheme of things. After some more nut cracking we came down to the following 2 alternatives:
A) Svc <> Page <> View Mode control <> Edit Mode Popup
This basically suggests that the data coming in to the page from the Svc should be passed on to the page as it is, the page to the View Mode, and the View Mode to the Edit mode and similarly all the way back. Fundamentally, each entity will interact only with the one in front of it and the one behind it. That is, the page will never interact with the Edit pop up directly, the View mode will never interact with the Svc, ie make Svc calls.
B) Svc <> Page <> {View Mode control, Edit Mode Popup}
In this arrangement, the Page can now interact directly with the View and Edit controls. That is the only difference between this and the previous arrangement.
Now for anyone to understand the implications of either arrangements, i need to highlight the interactions between a control and the page. The control will have all the buttons to actually perform operations by the user. But they will not be any Svc calls emerging directly from the control itself. On a button click, the control will raise a Button_click event which will be handled in the page by the required Svc call. It may seem complex, but if you have read my previous posts, which i mentioned earlier in this post, then you will realise that with such an arrangement you have actually decoupled a UI fragment from the data processing unit (the page) and data supplier (the svc). With that, you can actually use the same control in a similar context with a different svc and processing unit, giving similar data. Similar interactions will exist between any two controls as well.
Now with that out of our way, let me get to the point. In arrangement A, the work is distributed across the entities. There isn't a lot of control resting in one place. A fair amount of modularity will be introduced with that approach. And hence the over all code will be neat and clean. But if a change is required it will have to be done at multiple locations. While in arrangement B, with the page interacting with both the View and Edit controls, the Page will end up managing a lot of Events that will get raised by double the number of controls as compared to that in A (assuming that each View Control has an Edit control). This will localize the code, resulting in the reciprocal of arrangement A. The code will be difficult to manage with so much happening in one place, and hence the code can get ugly. Mind you with effective code management this can be resolved. But at the same time, if there is an error or change in the way the data is processed, there will only be one place where all the changes will have to be made.
Which will anyone pick is a matter of great debate and discussion. The correct answer depends entirely on the situation at hand. I picked one of them based on the existing code structure, so that is an important parameter while making such decisions. And for those who will suggest that should merge the View and Edit modes: solve the problem, don't change the requirements.