MVCがWebフレームワークに対してなぜ間違っているのか?

我々は長い間、Web開発のMVCによって毒されている.
MVCがWebフレームワークの前に以前に導入されたので、大部分のウェブフレームワークはそれを無謀に使っています.
ほとんどのWebフレームワークのクリエイターも、Webロジックとビジネスロジックの間に異なる知っていない.
Webフレームワークがどのようにしなければならないかだけでなく.
彼らはちょうどMVCがそこにある必要があります.
しかし、あなたが尋ねるならば、なぜWebフレームワークはMVCを必要としますか?誰も論理的に説明できない.Webフレームワークの中でMVCを使用するロジックがないからです.
MVCでWebフレームワークを使用していたとき、私は常にコントローラーによって混乱しました.
私は、コントローラがウェブ要求とビジネスロジックであるかどうか知りません.
実際には、Webフレームワークには以下のようないくつかのことが必要です.
ウェブ要請を取り扱う

の処理要求

はデータ

を返します
Webフレームワーク処理システム、ユーザロジック処理システムには、基本的な2つのシステムがあります.
しかし、ほとんどのWebフレームワークは、Webリクエストとユーザーロジックを1つのコントローラにミックスします.
とMVCのビューでデータをミックスします.
Webフレームワークの場合、実際にはユーザロジック処理に干渉する必要はありません.これらのWebフレームワークは非常に基本的なフレームワークです.js
我々が今知っているように、1つのコントローラを持つ1つのルートは確かに良いウェブフレームワークになる正しい方法ではありません.Web要求は、異なるルートのために同じ処理を共有するかもしれません.
と同じルートを持つHTTPメソッドの異なるプロセスを持つことができます.
良いWebフレームワークでは、これらの2つのシステムを適切に扱う必要があります.そして、これらのものをうまく扱う

ウェブ要求ルーティングと

を浄化しているリクエストデータ
ブリッジは、ユーザー・ロジック/ビジネス論理処理システムにウェブリクエストデータを渡して、ウェブ応答にデータを取り戻すブリッジ

は、処理されているロジック/ビジネスロジックを使う方法を楽しませます.

ビジネスロジックのフックをコントローラにWebフローに追加します.

実際にはMVCとは何の関係もない.それらのものは、私がそれをウェブ直線に付けるウェブ流れの上にすべてです.このチャートのように記述できます:

ほとんどの順序の方法で最も便利なWebプロセスの詳細.
Webストレートには、Webフレームワークがどのようなものであるか、なぜMVCがWebフレームワークに必要でないのかがわかります.
また、Web直線の実装もあり、ノードを使用してaexを呼び出します.JSとタイプスクリプト.
AEXでは、コントローラを必要としませんが、別のリクエストを処理するのに使用されるクラスの内部でハンドラーを使用します.
ここでは、Webリクエストを処理するためにAEXを使用する簡単な例です.

import { Aex, http } from "@aex/core";

class UserLogic {
  private parameters;
  constructor(parameters) {
    this.parameters = parameters;
  }
  @http("get", "/user/process1")
  public handler() {
    this.userLogicProcess1()
  }

  private userLogicProcess1() {
     // ....
  }
}

注意:

This web flow is applicable in most languages.