I understand that the model should generally consist of data manipulation and the view for data display from the model, but how do I keep my model and view layers decoupled?

My simple view has a few tables that display data. Its associated model manipulates the data based on the view's type of TableModel. Most of its methods involve using the TableModel type. Should the view generally "breakdown" the data into a more generic type of integers and strings for the model? Therefore all the model handles are simple generic lists of data without needing to use TableModel in case the view is changed into another interface. The model should be "unaware" of the view for good programming practices, right? If I change my view to a command-line interface, the associated model should still be able to perform its functions, given the correct associated Lists of integers/strings/whatever.

  • Could you clarify what your problem is? It sounds like you are asking "how do I keep my model and view layers decoupled" but I honestly can't tell. Your comment about a command line interface doesn't really fit with your question and creates further confusion. Please edit your question to provide a little more context. – mortalapeman Jan 31 '13 at 5:24
  • @mortalapeman edited, and yes - I am trying to docouple them. However, I am not so sure that using the same data types in the model as well as the view is the correct path. Perhaps breaking the data down into simpler, more generic types is the best practice. – Justin S Jan 31 '13 at 5:31

The first thing to understand is that the decoupling between model and view is only one-way. The model should not care how its data is presented to the outside world (it should be unaware of the view other than possibly knowing something is observing the model).
The view on the other hand does have knowledge about the model, in particular about how to get data out of it.

In an ideal world, the model should expose its data in a way that is convenient for the model and the concepts it represents. The view has to conform to the API of the model.

In the real world, people will want to reuse widgets across different projects, so you get libraries of widgets that expect a certain common API from the model they work with, often in the form of a generic abstraction such as a list, table or tree. In such cases, it is often easier to let the model reflect the generic abstraction it fits best with (with the associated common API) and to augment the interface where appropriate.
Although the model's API has been adapted to meet common view expectations, the two are still decoupled, because the model does not know which portion of the model gets actually presented in the view and how it gets presented.

| improve this answer | |
  • 1
    or have a specific interface between the shared widget implementation and the model, which you implement in the project's view as a abstraction layer between view and model. like javax.swing.*Model interfaces – ratchet freak Jan 31 '13 at 10:41
  • @ratchet freak Using an interface is an excellent idea. – Justin S Jan 31 '13 at 16:29

You're missing a layer. You need a controller. The controller's job is to take data from the model, whatever your model abstraction might be, and to then use that data to populate the view, do page logic, etc. MVC is the traditional model/view paradigm. My web application, here, is written in python and takes aadvantage of an MVC framework called Web.py. You can see the way the models and the views are separated by a controller layer, who controls the view.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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