1

クライアントとサーバーの両方でMVCパターンを使用する理由を見つけるために数日間努力しています。現在、サーバー側でMVCフレームワークを使用しており、RESTfullAPIを作成しました。jsrenderを使用してテンプレートを作成しました

<script id="housestemplate" type="text/x-jquery-tmpl">
    <li><a href="#" onclick="gethouse({{:house.id}});">
        <h3>{{:house.house_type.type}}</h3>
        <p>{{:house.area}} {{:house.bedroom_num}}</p></a>
</script>

次に、ajaxを使用してテンプレートを取得してデータを入力します

        $.ajax
        ({
            type:"GET",
            url: url ,
            success:function (data) {
                $("#renderHouse").html($("#housestemplate").render(data));
            }
        });

Javascript MVCフレームワークは、クライアントとサーバーのコードで繰り返されるモデルとビュー（テンプレート）でDRYルールを破ることなく、この機能をどのように改善できますか？

4

1 に答える 1

2

that特定の例では、それは間違いなくやり過ぎであり、単純な javascript/jquery を使用する方が適切です。

ただし、javascript/jquery の量を 500 行程度に増やします。それはどのように見えますか？管理可能？1000-2000 LOC はどうですか? ここで、すべてのコードをオブジェクト (クラス :) として編成し、バックエンド サービスがどのように編成されているかのように相互に対話できるメソッドがあればいいのにと思うでしょう。うーん...だから何？backbone.js が役に立ちます。コードを MVC(C) パラダイム (後者の C はCollection) に編成するのに役立ちます。したがって、フレームワークの一部としてコードの編成とイベント駆動型の通信が得られ、前の 2,000 行のコードが最初からそのように編成されていればよかったのにと思うでしょう。

それで、バックボーンはあなたに何を与えますか？コードの編成とスパゲッティの防止。実際、UML のような分析 (クラス図など) を使用して、アプリケーションの「フロントエンド」を分析および設計し、より保守しやすくすることができます。

それであなたが聞きたい質問は、それだけの価値があるかということです。それは、期待する JavaScript の量と、フロントエンドの範囲/サイズによって異なります。@jakeeが指摘したように、クライアント/サーバーを異なるレルムで実行していると考えると役立ちます。

頑張ってください！

于 2012-06-21T16:49:18.303 に答える