I'm a newbie on web development and I've heard about MVC.
If I'm right, it's the Controller that take charge of fetching data from DB.
So I have a question:
In the pattern MVC, how many objects to interface with DB should I use?

For example, in my web project, there are two controllers: ControllerA and ControllerB. I have two options:
1) Generate only one object to interface with DB, and the two controllers will use the same object.
2) Each controller will have its own object to interface with DB.

  • I would not recommend clear MVC - use MVC+DDD instead Commented May 29, 2017 at 8:23

2 Answers 2


In MVC the DB doesn't matter. Doesn't even have to exist.

The model matters. The two controllers talk to one model if they talk to the same model. They talk to many models if they talk to different models.

Any one model could talk to one, many, or no DBs. That's outside the concern of MVC.

The model isn't a code word for the DB. It's the code responsible modeling the state of your system. In a chess game it knows where the pieces are. In a web site it knows if the user is logged in. The DB doesn't have to know any of that. The DB, if it even exists, knows what needs to be remembered. It's responsibly is persistence. Not modeling.

This is particularly true in the web where one of the models is kept in the web client.

  • so, i can't design app only with MVC?))) Commented May 29, 2017 at 8:39
  • Oh you could but that would be fairly limiting. MVC is three areas of responsibility. There are other useful areas as well. Commented May 29, 2017 at 8:49
  • so, I can't design app only with MVC? You can. MVC is agnostic to the data source
    – Laiv
    Commented May 29, 2017 at 9:16

MVC is an architectural pattern that focuses on separation of concerns. This means, every component in your application should do only one task and do it well. It is this concern that helps identify the components as Models, Views and Controllers.

Usually, a resource (typically a record in a DB) is represented as a Model. Say, you have a table for users in a website. A corresponding model named something like UserModel would expose all the relevant APIs to Create, Retrieve, Update and Delete a user from the DB.

The Controller would typically be the gateway to your application. The logic of delegation would reside here. For example, if you needed to bulk edit users, a request to a controller (perhaps named as) BulkUserController would expose an API to edit multiple users. This controller in turn would delegate the edit task for each user in request to the UserModel. Note that the Controller just handles delegation here.

Now, coming back to the question about interfacing with the DB. Since the models represent the resource, they are the ones that interact with the DB. This means, controllers such as BulkUserController and SingleUserController (for lack of imagination) would interact with UserModel which in turn interacts with the underlying instance of the DB interface. Typically the instance of the DB interface would manage a connection pool to the DB for executing parallel queries on the DB.


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.