MVC: how to design interface for database

Question

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.

Answer 1

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.

Answer 2

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.