Configuration vs MVC?

MVC is the "standard" application development philosophy, so it may raise eyebrows, to say the least, to admit that a configured approach, such as Lucidium, deliberately breaks its principles...

A "configured" application platform gives the developer/implementer a configuration model to build the business functionality with. As with Lucidium, this configuration model may fit the MVC paradigm to some extent, e.g...

• Model = Entities (i.e. tables), Fields, Security Rules, etc (1).
• View/Controller = Pages, Sections, Page Script Code, Page Links, Menu Structure, etc (2).

However, there are overlaps:

• the Model contains some View/Controller information, e.g. whether each field is shown or hidden in tables or lists, as well as Model stuff, like whether it is editable or not, and mandatory or not (3).
• the View/Controller contains some Model information, e.g. business logic embedded in Page Script Code (4).

In addition, the View and Controller elements are integrated in a single UI configuration, representing Pages, Sections within them, and navigation routes (5).

Thus the principles of MVC are compromised in the very thing they seek to do - keep the Model and the UI separate.

How bad is this?

Well, to answer, I start from the key rationale for the configured approach:

The UI Layer is a significant larger development effort than the Model, and (for administrative functions at least) it follows from the Model, and can be derived from the Model, allowing changes to the Model to be automatically reflected in the UI.

Hence it's okay for the UI Layer configuration to depend on the Model configuration (3), but not vice versa (4).

A key issue for the configured approach is "what happens when the configuration model doesn't support the thing you need?". Inevitably, you need to roll up your sleeves and code. But where does the code go? How does it affect your configuration?

Of course, with the "code generation" approach, you hit the problem that manually hacking the resulting code usually breaks the link to the configuration - you can't regenerate the code without losing the manual changes, so you never regenerate again...

Even with dynamic approaches, such as Lucidium, the code may not end up "in the right place" - i.e. UI Layer code in the UI Layer, and Model code in the Model.

BUT - these are all questions of degree - the crucial point is:

A configured approach can be consistent with MVC principles, and a well-designed configuration model can obey those principles to allow Model changes to impact the UI Layer, but not vice versa...