web-dev-qa-db-ja.com

リポジトリレイヤーをビューおよびコントローラーと同じファイルにマージする方法でWebアプリケーションを記述することの何が問題になっていますか？

ビュー、リポジトリ、コントローラを同じファイルにマージする方法でコードを記述することに問題はありますか？

つまり.

global $db;
// or $db = DBSingleton::get_db_instance();
// or global $container; $db = $container->get(Db::class);
$id = filter_var($_POST['id'], FILTER_VALIDATE_INT);
$record = $db->parameterized_query("SELECT data from table where id = ?", [$id])->getResult();
foreach($record as $row)
    echo $row['data'] . PHP_EOL;

など基本的にすべてが同じファイルにあり、依存性注入の使用、ビューコード、データベースアクセスコード、および「HTTPリクエストオブジェクトからの変数の読み取り」が同じファイルにある場合は、ほとんどありません。

なぜ現代のフレームワークはこのスタイルに反対しているのですか？このコーディング方法を仕事で使用することを選択した場合、何が問題になる可能性がありますか？

phpcoding-styledependency-injectionanti-patternsseparation-of-concerns
2
Dennis

何も問題はありません。 懸念の分離 を失うだけです。

Vueを使用すると、この方法で単一ページのアプリケーションを正確に作成できます。 Visual Studio Codeでのコードの折りたたみにより、読み取り可能な状態が維持されます。

しかし、そのようなページの実際的な制限は、約20,000行のコード（HTMLを含む）です。これは1つのファイルに含まれる多くのコードであり、アーキテクチャの空気が不足する前に、かなり小さなアプリケーションに制限されます。次に、コードを個別のファイルに分割します。

最小のアプリケーション以外の場合は、ニーズの拡大に応じてアプリケーションを自然に拡張できるアーキテクチャを使用してください。

6
Robert Harvey

すべてのコードを1つのファイルにマージし、関数を使用しない（コード例が示すように）と、抽象化によって得られる利点もなくなります。関数でさえ、適切に名前が付けられた場合、ロジックだけでなく、ロジックを理解するために時間を費やす代わりに名前を読み取るだけでプログラマが理解できるアイデアをカプセル化する抽象概念です。

この方法で書かれたプログラムは非常に直線的であり、コードの再利用は事実上不可能です。

関数を導入すると、コードの再利用が容易になり、関数を使用しないアプリケーションと比較すると、抽象化を活用できます。その時点で、手続き型プログラミングの領域に入りました。しかし、これにも限界があります。

関数をグループに整理しない限り、単一のファイル内のグローバル関数の寄せ集めは、管理および頭の中で追跡することが困難になります。この時点で、機能の明確な説明が表示されるようになり、これらの関数グループを独自のファイルに引き出します。次に、これらの関数と共にデータをバンドルする必要があるので、これらの他のライブラリファイルでグローバル変数の宣言を開始します。これで、オブジェクト指向コードがはるかに役立つしきい値に到達しました。

これは複雑さの低いものから高いものへの自然な進行と言えますが、1行のコードを書く前に、これがどれほど大きくなるかを判断する必要があります。ほとんどのアプリケーションは「単一ファイル」を超えて非常に急速に成長するため、アプリケーションを複数回再構築する必要があり、開発が不必要に遅くなります。

エンジニアとしての私たちの課題は、解決が必要であることがわかっている問題に対して適切に複雑なアーキテクチャを構築することであり、アプリケーションの進化に関する経験を踏まえてです。大多数のアプリケーションは、1つのファイルに収まらず、目立たないようにする必要があります。これにより、開発を最小限の複雑さ（少なくとも懸念を分離する）にすることができます。

機能を簡単に追加し、既存の機能を変更できると同時に、まだ必要のない機能や抽象化を構築しないアーキテクチャが必要です。それが課題です。

4
Greg Burghardt