MVC two models required?

Question

I've been doing software for a long time, but almost all of it has been back-end centric.

I recently decided to learn Swing and tried to apply MVC principles. I realize that in Swing the View is handled for you by the components you add to the window/frame/panel, and the Controller is your code responding to the events. However, when it comes to Model I quickly found that I needed TWO models. One is the back-end model representing the underlying data universe. That model is completely unaware of the UI and the fact that it's even being displayed. The second is a version of the model with additional attributes governing display-related aspects.

For example, the project I chose was a tool that cross-references the database instances, schemas and tables in a huge enterprise application containing 140 db instances, several hundred schemas and thousands of tables. Sometimes when looking at unfamiliar code you have a table name but finding which instance and schema it's in is a chore.

The tool displays 3 columns: DB Instance, Schema and Table, and each column contains only unique names. When you click on a table name (for instance) the schema and instance columns get filtered showing where that particular table occurs. Clicking on a schema name or instance name results in similar filtering behavior on the other two columns.

I have a backend model containing a three-level tree (Instance, Schema, Table) but this is inappropriate for the UI I want to display. So I have a second "display-model" that is built from the backend model, and backs the three columns. That is where I store flags indicating which entries are visible based on user input. The two models are significantly different in structure, and the display-model entries contain references to the backend-model entries. In a sense the display-model entries are adapters that allow the backend-model entries to be handled in a display-appropriate way.

I haven't run across any references to this, but my gut feel is that this must be a very common problem. Has anybody else run into this issue, and what are the "accepted" UI programming ways to accomplish the objective?

Answer 1

This is a fairly common situation and your choice of pattern is very dependant on the circumstance and your personal preference.

Where you're not simply writing a CRUD application, you can have a domain model which models the business domain and a view model, specific to the application, for displaying and editing that data. Some would argue that even when the two models look the same, you shouldn't expose your data model directly to the view anyway.

Or you can consider the domain to include more than just your data (known as Fat Models), in which case the way that you access it -- the API exposed to your front-end application -- doesn't have to relate to the way that you store it in any sense.

Also have a look at the related pattern called Command-Query Responsibility Segregation. This is based on the theory that the data model you use to manipulate data is almost always different from the data model(s) you use to view the same data. It draws a very distinct line between the two and allows you to develop the two independently.

Answer 2

I agree with pdr that this is a common situation – in fact I’ve been dealing with it throughout my 20 years in software engineering. Consider the simple case of a managed database and its users. Users write queries to return result sets. Result sets are tables – so each user can build their own model from the internal data model. At some point a user asks the DBA, “Can you add this query to the db as a view so I can query against my own abstraction?”

The same issue arises with “Command-Query Responsibility Segregation” or whatever pattern, diagram, or scheme anyone dreams up. You can’t segregate the models because the models have to interface with one another. The provider and the consumer have to speak a common language.

In my experience, flexibility has to be architected into both sides, that is, there has to be a mechanism for the provider to expand the data model so as to offer compound objects, views, or some similar facility of that kind to provide the higher level abstractions clients require. And also, clients need to be able to build further higher level abstractions in their own domain in a clean maintainable way. If these two facilities aren’t designed into the system, programmers will kludge them, and your code base will become a nightmare, eventually useless.