I got into a debate at work today, I hope you can help me to settle it up.

My colleague wants to separate UI, Model, DB, and Network like so:

  • Create an API level between UI and controller, that will allow the UI to query all the models in the APP.

  • There will be another controller that will break the models into their DB representations (Ex: UserTablesModel, ScoreTableModel...), It will be a singleton called DBControler and it will also provide some utility methods to query the DB (Ex: insert(tableName, value...).

  • The ModelTables will use events hub to notify UI with state changes, and they will be updated from the network layer using DBControler reference.

I don't like this idea as it creates a coupling between unrelated models in the controller layer. I think it would be wiser to allow the UI to have direct access to Models (maybe make them singletons) and it's up to the model to offer a proper API to access its data and provide an events callback to notify his state change (no events hub). I like the part that models need to be directly updated from the network layer.

Also I don't like the name TableModel, I think the DB needs to be a service accessible by the model, one model can access multiple tables.

What is the proper way to work with MVC?

  • Things you never see in a software department: One developer looks at another's code and says "I'd have done it exactly the same way!"
    – Robbie Dee
    Commented Nov 10, 2015 at 11:19
  • @RobbieDee tnx Robbie, it's very funny what you just say, it also might be true and interesting. How ever I am seeking for more professional and meaningful answers. Commented Nov 10, 2015 at 11:23

2 Answers 2


I'd seriously recommend looking into viewmodels. How the data is presented in the database isn't always how you'd want it presented in the UI.

A common example is prices - where it might be stored as an int or decimal in the DB. However, in the UI, you'd maybe want the currency symbol and digit grouping so:

$1,999 rather than 1999.

Adding this logic to the UI or model makes no sense - and with a viewmodel, the UI & model can be kept clean: the UI just serves up the data, the viewmodel only contains the data and logic required, and the model stores the initial representation of the data.

This page describes its use in ASP.NET MVC, but the general principles are sound.


I'd recommend Knockoutjs(simplyfy dynamic Javascript UIs), Model View-View Model(MVVM) architecture pattern.

Usually in MVC pattern, Model will hold all data, View is for UIs, and Controller will connect UI and Model.

In MVVM pattern, Model-View will display data from your database, View-Model will hold data temporarily based on UI input, once submit or save, Controller now do its work to validate and save it to your Database.

Analogy: 1. I give you candy and you hold it in your hands (MVVM) but you can
return it to me, loop.. 2. If you eat it, and its done (Controller)

  • try this link, www.knockoutjs.com/examples/contactsEditor.html
    – kheLthusad
    Commented Nov 11, 2015 at 3:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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