Let's assume we have a class structure for a particular application (a University manager for example, with classes representing semesters, subjects, timetables and so forth). It is to be a desktop application (WinForms for instance), with data being held in an Sqlite database backend. The schema for this database is based on the UML class diagram, with classes being mapped to tables, class attributes mapped to table fields, and many-to-many relationships represented by link tables.

I understand that the Model should manage all the rules and logic of the application, and contain all the data. What would be the best way to manage displaying this data (for example, displaying a list of all classes available in a particular semester in a suitable UI control in the appropriate form, and to enter data (creating a new student profile). Should the appropriate data be fetched from the DB and placed into instances of the objects, which are then used to fill out the fields in the UI widget? the same goes for inputting data. For example, when creating a new student profile, should that data be used to create a student object, which is then used to fill in the appropriate DB table?

The core of the question is, was the effort of designing the class structure with CRC methods and creating a UML diagram a wasted effort? Is the class structure redundant, since the data can be placed into the DB or retrieved from it without this class structure? The Model would function as a means of executing queries to achieve this, based on commands from the controller.

1 Answer 1


In an MVC the Model is not a database. MVC is a pattern to split the concerns and responsibility of the UI, and you can have a UI CRUD build with the MVC pattern without a database. The data could be stored in memory or some backend using REST API calls.

The class structure is not redundant with the database because the way you store your data should not be coupled with the design of your system. Although people tend to reflect the UML diagram in the relational database you can not do that with other types of databases like a document or key-value databases.

  • That makes it more clear to me what the Model should be. From what you've said, it seems to me that such an MVC application should function even without a connection to a database. In this case, the class structure is absolutely necessary, since it would facilitate the creation of objects to hold the data. When a database is used, the Model should also facilitate making queries to the database for data input and output. Is this correct?
    – Al2110
    Commented Nov 6, 2019 at 11:58
  • That´s it. You got!
    – Edu Costa
    Commented Nov 6, 2019 at 12:00
  • If the application has a connection to the database under normal operating conditions, should the class structure be used, as I described in the post, or should the Model directly make queries to the DB without creating objects? It seems like this may be overkill, if the DB is always present, especially if it is Sqlite. On the other hand, it may be necessary in case the connection to the database is lost.
    – Al2110
    Commented Nov 6, 2019 at 12:06
  • It´s not recommended to mix database code with other parts of your System. The interaction with the database should be hidden and used through an interface. You can you the DAO Pattern per example.
    – Edu Costa
    Commented Nov 6, 2019 at 12:24
  • 2
    @Al2110 Controler and View should talk with the Model, using the classes and services offered by the Model. The Model is responsible for the data consistency and if you would short circuit it, this consistency would be much more difficult to maintain. If later you want to change Sqlite to something else, only Model would have to be revised, the View and the Controller should be unaffected.
    – Christophe
    Commented Nov 6, 2019 at 12:26

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.