I'm working with a framework where the fields displayed on each web page are defined in the application database. Administrators can add new fields to pages or hide/completely delete old fields. The logic for each page is in a Java class - sometimes there's a one-to-one relationship between a page and a class, sometimes several pages use the same class.
This framework design creates a hidden dependency between the page data in the database and the logic in the Java class. If a new field is added to a page, the matching Java class must provide that field - or the page will break. The Java code has no compile-time knowledge of how the page is configured in the database (each customer database may have different configurations), which increases brittleness.
A typical solution has been to SELECT * from one or more database tables, allowing a degree of configuration as to which fields can be displayed. This leads to database-centric Java code with plenty of embedded SQL and little object-oriented design or domain models.
We've introduced a three-tier MVC-like architecture (controller -> service -> repository) with object-oriented models to the framework. It limits the ability to add fields to the pages without changing the underlying code. However, the change makes it possible to program in an object-oriented way and create domain models. Next up, we're planning to do something about the dependency between the database and code.
My long-term plan would be to move the page definitions from the database into the code (your standard HTML&JS views), limiting configurability but reducing brittleness. Any incompatibilities between the pages and Java would then become compiler errors when building the application instead of runtime errors.
- Do you consider the framework practice of defining the view in the database and the controller in the code as sound design or something that should be addressed?
- If you think the situation should be addressed, does my long-term plan seem reasonable?
In addition to defining the layout, the view definitions in the database define which fields are expected to exist - "get field 'foobar' from the controller and show it here". The views themselves don't really contain logic. The Java classes backing up the views typically contain thousands of rows of UI and business logic.