MVC,MVC,MVC… but how to resist to the bad temptations?
Posted in Quark framework, UI design on August 28th, 2010 by sinica – Be the first to commentOne question that sooner or later the architects of a MVC framework should ask is how the system will be dealing with creation of error messages and pop-ups. In Quark,we are trying to be consistent with our philosophy of strict separation and one single sense communication between model,view and controller. Given that, a simple solution like calling PopUpManager.Show from view,model or controller it is not possible or a good thing. Other framework have the luxe of using Facades and Mediators to put code like PopUpManager.Show and do there the dirty work but we want to keep things simple and editable from UI.
Our solution is a bit abstract but it is using the MVC as it should do: there should be always a special place in model where a controller can add a message or an object instance and that cause automatically the view to show a popup! Basically, we just create a convention and we expect quark’s view components to follow. That special place can be for example a special metadata member for the current data object.
Conclusion: in quark, pop-ups get displayed when they are requested by model or controller by stetting values in metadata and they are never directly displayed using direct calls.
What benefits do we see here?
- the code needed to create an application is shorter,cleaner and easier to write and maintain
- the code for quark based applications have very few dependencies on platform’s APIs,the code is focused on user’s problems and just follows a few standard conventions to achieve its goals. That will make easy in future to write quark like platforms in Java Script,Silverlight or any other technology and having the final application still working perfectly.
- this is a practical approach for having MDA’s advantages without UML or other abstract and esoteric technologies. We try to minimize even the design patterns we use inside of the framework but should not be a concern for the final user of the framework.


