MVC のビジネスロジック [closed] 質問する

Fist of all:
I believe that you are mixing up the MVC pattern and n-tier-based design principles.

Using an MVC approach does not mean that you shouldn't layer your application.
It might help if you see MVC more like an extension of the presentation layer.

If you put non-presentation code inside the MVC pattern you might very soon end up in a complicated design.
Therefore I would suggest that you put your business logic into a separate business layer.

Just have a look at this: Wikipedia article about multitier architecture

It says:

Today, MVC and similar model-view-presenter (MVP) are Separation of Concerns design patterns that apply exclusively to the presentation layer of a larger system.

Anyway ... when talking about an enterprise web application the calls from the UI to the business logic layer should be placed inside the (presentation) controller.

That is because the controller actually handles the calls to a specific resource, queries the data by making calls to the business logic and links the data (model) to the appropriate view.

Mud told you that the business rules go into the model.
That is also true, but he mixed up the (presentation) model (the 'M' in MVC) and the data layer model of a tier-based application design.
So it is valid to place your database related business rules in the model (data layer) of your application.
But you should not place them in the model of your MVC-structured presentation layer as this only applies to a specific UI.

This technique is independent of whether you use a domain driven design or a transaction script based approach.

Let me visualize that for you:

Presentation layer: Model - View - Controller

Business layer: Domain logic - Application logic

Data layer: Data repositories - Data access layer

The model that you see above means that you have an application that uses MVC, DDD and a database-independed data layer.
This is a common approach to design a larger enterprise web application.

But you can also shrink it down to use a simple non-DDD business layer (a business layer without domain logic) and a simple data layer that writes directly to a specific database.
You could even drop the whole data-layer and access the database directly from the business layer, though I do not recommend it.

[注:] また、最近のアプリケーションには複数の「モデル」があるという事実にも注意する必要があります。通常、アプリケーションの各レイヤーには独自のモデルがあります。プレゼンテーション レイヤーのモデルはビューに固有ですが、使用されるコントロールとは独立していることがよくあります。ビジネス レイヤーにも「ドメイン モデル」と呼ばれるモデルがあります。これは、ドメイン駆動型アプローチを採用する場合によく発生します。この「ドメイン モデル」には、データとビジネス ロジック (プログラムのメイン ロジック) が含まれており、通常はプレゼンテーション レイヤーから独立しています。プレゼンテーション レイヤーは通常、特定の「イベント」(ボタンが押されるなど) でビジネス レイヤーを呼び出して、データ レイヤーからデータを読み取ったり、データ レイヤーにデータを書き込んだりします。データ レイヤーにも独自のモデルがある場合があります。これは通常、データベースに関連しています。これには、一連のエンティティ クラスとデータ アクセス オブジェクト (DAO) が含まれることがよくあります。

問題は、これが MVC コンセプトにどのように当てはまるかということです。

回答 -> 違います!
まあ、ある程度はそうですが、完全にではありません。
これは、MVC が 1970 年代後半に Smalltalk-80 プログラミング言語用に開発されたアプローチであるためです。当時は GUI やパーソナル コンピューターは非常に珍しく、ワールド ワイド ウェブも発明されていませんでした。今日のプログラミング言語と IDE のほとんどは 1990 年代に開発されました。当時のコンピューターとユーザー インターフェイスは 1970 年代のものとはまったく異なっていました。MVC
について話すときは、そのことを念頭に置く必要があります。
Martin Fowler 氏は、MVC、MVP、そして今日の GUI について非常に優れた記事を書いています。