mvc - 非 Web グラフィックス アプリケーションでモデル ビューと他の要素との関係をどのように扱うか?
習慣沉默
習慣沉默 2017-05-16 17:06:34
0
1
564

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

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

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

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

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

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

習慣沉默
習慣沉默

全員に返信(1)
世界只因有你

ちょっと待って、なぜ 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
人気のチュートリアル
詳細>
最新のダウンロード
詳細>
ウェブエフェクト
公式サイト
サイト素材
フロントエンドテンプレート