MVCとECSの違い
コンポーネントエンティティシステムアーキテクチャを使用して（ゲームではなく）アプリケーションを構築することは妥当ですか？ と、他のアーキテクチャ設計と比較したECSについての彼の説明パターン。
Angular5とUnityをよく使っています。 ECSとMVCの違いは何なのかと自問していますが、ECSとMVCは似ているように見えますが、違いもあります。頭を抱え込むのに苦労しています。
Entity-Component-SystemとModel-View-Controllerの違いを尋ねるのは、ハンマーとのこぎりの違いを尋ねるようなものです。どちらもツールボックスのツールですが、さまざまな目的で使用されます。
ECSとMVCでは、どちらもソフトウェア設計パターンですが、さまざまな問題を解決します。
それらについての他のすべては完全にそして完全に異なっています。
したがって、[〜＃〜] mvc [〜＃〜]は、GUIs/presentationを中心とした建築スタイル/パターンです、および（a）ビジネス/ドメインロジック（からのプレゼンテーションロジック（UIに関連するもの）間の結合（相互依存性）の制御（ （b）いくつかのバリエーションでは、プレゼンテーションレイヤー自体で何が起こっているかを制御すること（データと動作をGUIからビューの抽象化を表す個別のクラスにプルする可能性がある場合） ）。
アプリケーションの残りの部分、具体的にはドメインロジック、つまりアプリケーションのコアを構造化する方法については、実際には何も規定していません。これは、MVCのコンテキストでは「モデル」という用語に該当します。
ここに定義された特定のコンポーネント（ビュー、コントローラー/プレゼンター、モデル）があり、どのコンポーネントが他のコンポーネントに依存する必要があるか（本質的に、モデルは何にも依存せず、ビューとコントローラーは依存できる）パターンのバリエーションに応じて、互いに程度は異なります（また、データバインディングや、命名規則に基づく更新通知のサポートなど、特定のメカニズムが使用される場合もあります）。
注：「Web MVC」（サーバー側）もあり、同じアイデアの一部を借りますが、別のことも行いますが、私はそれについて言及していますさらに調査を行った場合、同じと呼ばれるさまざまなものが存在することを知っているだけです。
[〜＃〜] ecs [〜＃〜]は、一方で、さまざまなエンティティとサブシステム間の複雑な関係（複雑なシステムを構築することを目的としています）概念的に分離する）、および要件（およびコードの詳細）が開発中に頻繁に（そして大幅に）変更される可能性があるという期待。それが本当に解決しようとしている問題です。繰り返しになりますが、いくつかの定義された概念的な部分と依存関係の方向があります。アイデアは、これらのサブシステム（ゲーム開発の場合、レンダラーのようなもの、または物理システム）は、操作する必要のあるさまざまなエンティティーに依存すべきではないということです（これにより、サブシステムについて何かが変更されるたびにこれらのサブシステムを変更する必要が生じるためですエンティティ）。代わりに、（サブ）システムとエンティティの両方が、さまざまなコンポーネントによって表される抽象化に依存するようにすることで、依存関係が反転します。データ指向のバリアントでは、コンポーネント自体は実際には単なるデータバッグであり、動作はありません。詳細については、質問にリンクした（本当に素晴らしい）投稿で読むことができます。一番下の行は、このアプローチでは、（サブ）システムは、（サブ）システム固有のコンポーネントを取り込むことにより、他のコードに何らかのサービスを提供するものです（コンポーネントに対して何らかの処理を行ったり、データを変更したりする可能性があります） 、または何をすべきか、またはその両方を指定するある種の構成として使用する場合があります）;エンティティは、そのようなコンポーネントのコレクションを保持するオブジェクトです。
最後に、これらのパターンを一緒に使用する場合、MVC内では、「モデル」コンポーネント（ドメインロジック）内でECSアプローチを使用する可能性が最も高くなります。