Controller by entity?

About your comment, I will try to complement giving more a personal solution:

Working in MVC:

To the graphic interfaces, either html or application interface with form and buttons, I will generically call them "screens".

The "screens" always have an intimately related component, a "screen driver" of their own to receive the events and actions performed.

In this "screen driver" you must have the minimum logic to bring the related screen to life. For example, when events are performed on the screens, there must be minimal logic in the controller, detecting what type of event was executed, what information should be prepared and stored in DTO and then invoke the CONTROLLER by passing the parameters that have been prepared. If it is in the opposite direction, that information is received from the controller to show in the view, the "screen controller" performs the minimum processing to, for example, divide the information packages that are delivered to it (for example, filter certain DTO that will show in a list of names, filter which will show in a list of products) and leave everything ready for the screens to show correctly without "thinking in any way."

Now, I complemented the layer seen like this:

VISTA

Screen

Display Driver

Now the CONTROLLER:

The controller contains functions or methods (java) with a specific name of the task it executes ... for example, there may be two functions: --- registerInformationandApplyStage (... parameters ...) --- ignorePersonaYLlamarALaPolicia (... parametros ...) According to which it is called, it will realize a DIFFERENT BUSINESS LOGIC.

In the controller, the information that is received from the view is taken, it reads the properties of the DTO on time, it determines what to do with the information (for example, from the telephone call the police, according to age see if it is legal that participates in a lottery) and prepares, again the DTO to send them to the MODEL layer to be saved, updated, etc.

The MODEL layer will receive those units of information DTO, when they invoke its functions and methods, and according to the function called, perform a specific function without performing any major processing. For example:

--- savePersonalInformation ()

--- savePersonalAdditional Information ()

Postscript:

Already in the world of Java EE business application development, we work with the "Architecture by Layers", I leave the following link Layered Architecture

For example in Java EE JSF, the "screens" have their intimately related "screen driver" called Backing Bean (also called Managed Bean)

What you have left, is to start developing example projects and always keep in mind that each layer, each component, each thing, fulfills a specific function and in one place ... that from the view is never called directly to the functions-methods of the model, which in the view do not perform calculations, etc.

Greetings.

I can tell you that it is correct to create a VO and a DAO for each table in the database.

You mention in your message the concept of Entity, which I feel is more related to the issue of ORM (type Hibernate, JPA ...) but that is already a topic of another level apart. I recommend consulting about the DTO (Data Transfer Object).

the MODEL layer is composed with the DAO and VO.

The controller layer, as its name suggests, manages that the actions performed in the view (for example, entering data, pressing buttons) are processed and generate data changes in the Model according to the "business logic" (function of your application). Also, from the data already stored in the MODEL layer are processed (perform appropriate calculations) in a suitable way to deliver them to the VISTA layer and you just have to present them in an appropriate way (and why not, pretty).

The layer of the VISTA if it is more thought only to present the information, should be as "gross" as possible, that it does not process any type of information with a business logic. At most it would be admissible for this layer to make, for example, data conversions (for example, from numerical values to text strings if the results brought from other layers can not come prepared as String).

By the way, in the MODEL layer you should not perform elaborate processing or calculations. The raison d'être of this layer is only to facilitate access (to consult, modify, insert or delete data) to a database manager to upload, modify and other data supported in it.

Sorry to leave the answer to the main question for the end: No, it is not necessary to create a controller for each DAO-VO-Table_of_BD. The controller must have correspondence of one by functionality I would say, and being so, also 1 view by functionality (minimum unit that performs a task, for example a functionality where a registration form is filled to a university)

These are answers thought at the level of your question. In the future, when you advance more in science and approach, for example, the Java EE world of Business Applications, you will see that the answer I give you has other interesting variations and complements.

Greetings.