I am developping a desktop application in C#, and have separated different layers in an MVC-ish architecture.
As I have switched from GTK# to XWT, only views had to be adjusted, so the seperation of layers was done quite OK.
As XWT does not have a layout designer, everything has to be set up in code, which in turn led to an architectural problem:
I have one controller for displaying outlets, inlets and connections.
This controller sends data to one view (outlined in red). This view in turn has subviews (green and blue), that only communicate with the view in red.
On scrolling / collapsing / expanding the treeviews, the green view send events, which are received by the red view, which in turn trigger redrawing in the blue view.
Controller does not see the green or blue views, every change in connections / outlets / inlets are only sent to the red view.
My problem: As I understand MVC, views should not have much logic. But the green views is a class of 300 lines, the red view's class has 200 lines, which is too many.
What architectural problem can arise from this? Am I overlooking a fault in my MVC logic?
Best Answer
The MVC design pattern was originally formulated in the old days when MS-DOS was still a dominant OS. In those days there was very little support from the OS for graphical user interfaces, so you had to do most of it yourself. In the original MVC, the job of the Controller was to figure out which text-entry field was active and what it meant if the user presses a key.
In the modern desktop OSes with display managers and feature-full widgets, that Controller role has effectively been merged into the View components and the MVC Controller has been given a more high-level coordinating role.
The logic in the Views should indeed be limited, but it should be limited to UI-related logic. For a View as complex as yours, even the UI-related logic can be quite significant, so I don't see any problems with your architecture.