Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

Schema Crossreference Tool UI Sample

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?

share|improve this question
    
I seriously doubt that you need two MODELS. "The second is a version of the model with additional attributes governing display-related aspects." This seems more of View than model. I would recommend that you go through the good MVC literature... –  apeirogon Oct 9 '12 at 15:47
add comment

2 Answers

up vote 5 down vote accepted

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.

share|improve this answer
    
Thanks, that link confirms I was on the right path (even if it is .net oriented :-) and is what I needed. –  Jim Garrison Sep 13 '12 at 22:10
    
@JimGarrison: MVC is MVC :) –  pdr Sep 13 '12 at 22:18
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.