検索

ホームページ  >  に質問  >  本文

mvc - 非 Web グラフィックス アプリケーションでモデル ビューと他の要素との関係をどのように扱うか?

今日私は苦情を申し立ててWeiboに投稿しました:
http://weibo.com/1651843872/B09Wxlokv?mod=weibotime

今振り返ると、jQuery のインターフェイスは大規模なアプリケーションにとっては有害である可能性さえあります。MVC の概念では、大幅に抽象化された明確なモデルが必要です。jQuery では、ビューはモデルに基づいてインターフェイスに同期されます。直接モデルとして運営されてます。ずっと迷ってました

私がフロントエンドを学んだのは、Web プラットフォームでのグラフィカル インターフェイスの開発が非常に安価であることに気づいたからです。
アプリケーションに取り組み始めて初めて、グラフィックス アプリケーションの複雑さを真に認識し始めました。
思い出してみると、この学習プロセスは、jQuery の使用とほぼ段階的に格闘するものでした。
モデル、ビュー、その他のコンポーネントとそれぞれの部分の分離は、徐々に現実的になっていきます。

DOM にはすでに抽象化レイヤーがあり、プロビジョニングの面でいくつかの道を妨げているため、Web は非常に厄介です
では、DOM を使用しない他のプラットフォームでのグラフィックス開発では、ビューとモデルの関係にどのように対処すればよいでしょうか?

たとえば、Webkit ツール ライブラリの基礎となる実装はモデルとビューを維持します。
Unity3DやFlashなどもありますが、この辺はどう理解していますか?

少し一般的な質問ですが、アドバイスをお願いします。

習慣沉默習慣沉默2796日前561

全員に返信(1)返信します

  • 世界只因有你

    世界只因有你2017-05-16 17:08:34

    ちょっと待って、なぜ jQ に反対するのですか? jQ は DOM 操作のカプセル化であり、MVC とはほとんど関係がありません。銃と大砲の両方で戦うのと同じように、「大砲は一発でバンカーを爆破できることを認識しているので、ライフルの使用は戦場に有害です」とは言えません

    実際、AngularJS は jq を使用しないことを推奨していますが、本質は jqLit​​e の使用を合理化することであり、Backbone は当然ながら jQ 寄りです。大規模なアプリケーションにはまったく構造がありません。jQ でハードコーディングするのは確かに間違った方法ですが、単純に jQ なしで MVC を実装すると考えるのは正しい考えではありません。

    参考のために昨年のBackboneのレビューを投稿します。実際のところ、「管理インターフェース」タイプのアプリケーションでない限り、Backbone または Backbone のような Model 機構、特に Backbone.sync用处不大。因为浏览器端的JS天生不『拥有』任何数据,不会负责数据的简单CURD式的落地(H5涉及离线本地存储另说)。浏览器端JS可能更需要的是维护数据和DOM绑定,也就是所谓ViewModel については、KnockoutJS を参照してください

    と今では考えています。

    Web の経験がなくて申し訳ありません。

    返事
    0
  • キャンセル返事