Model action under the ActiveRecord

Many frameworks now emulate Ror's ActiveRecord, which directly acts as a database interaction layer. And many of the business is not just for a table, some also contain logic outside the database, then I have to put these business logic in the controller processing.
This is not a violation of the controller's original intent---connect models and views of the bridge
Should I add a layer before the data model and controller?
How did everyone do it? database queries and business calls are mixed into the model? Can there be a framework to circumvent this?

Reply to discussion (solution)

Orm?
In a nutshell, ORM is the mapping of relational data in a database to objects in a program.

There is no definite dividing line between M, V and C in MVC
So in C, the completion of part of the entire business logic is not violated
As with continuous data discretization, different thresholds can be selected to achieve the same results.

I think the ORM-based framework just provides a prototype, and the application of specific projects needs to be further expanded
Due to the unpredictable nature of the application project, most ORM does not provide an association or provide only one interface

So it's better to change the model from table-based to view-based (the view is unpredictable, of course).

Learn.

Many frameworks now emulate Ror's ActiveRecord, which directly acts as a database interaction layer. And many of the business is not just for a table, some also contain logic outside the database, then I have to put these business logic in the controller processing.
This is not a violation of the controller's original intent---connect models and views of the bridge
Should I add a layer before the data model and controller?
How did everyone do it? database queries and business calls are mixed into the model? Can there be a framework to circumvent this?

Oh, I'm hungry. Can be a database specifically for a layer of encapsulation, and the model is responsible for processing business logic, the need to process data to call the encapsulated database module, so that the database module can be generalized to different model calls, and controller specifically control, so the structure is very clear.

Many frameworks now emulate Ror's ActiveRecord, which directly acts as a database interaction layer. And many of the business is not just for a table, some also contain logic outside the database, then I have to put these business logic in the controller processing.
This is not a violation of the controller's original intent---connect models and views of the bridge
Should I add a layer before the data model and controller?
How did everyone do it? database queries and business calls are mixed into the model? Can there be a framework to circumvent this?

Oh, I'm hungry. Can be a database specifically for a layer of encapsulation, and the model is responsible for processing business logic, the need to process data to call the encapsulated database module, so that the database module can be generalized to different model calls, and controller specifically control, so the structure is very clear.

Oh, I think I'm hungry.

Learn..... Daniel Mission

