3

現在、Webアプリケーションを設計していますが、顧客はASP.NET MVCまたはその他のMVCフレームワーク（Rails、Djando、またはその他のアプリケーションも適用されます）の使用について確信が持てません。

顧客は、これらのフレームワークを使用することに価値を見出していません。彼らは、従来のHTMLを使用し、JavaScriptを介してWebサービスを呼び出してすべてのデータを取得することを好みます。彼らにとってSOAは非常に重要であり、すべてのアプリケーションがSOA指向であることを望んでいます。現在の開発では、ホームページの初期ロードのためにいくつかのデータをビューに返し（ORMツールを使用し、コントローラーですべての計算を行い、モデルをビューに戻します）、ページの更新が実行されますJavaScriptを使用してRestServicesを呼び出す。顧客は、コントローラーを使用してビューにデータを返すことについて不満を持っています。彼らはすべてのデータをWebサービス経由で返すことを望んでいるため、MVCフレームワークは役に立ちません。MVCフレームワークの使用を「販売」するために顧客に何を言うことができますか？

各アーキテクチャを使用することの長所と短所は何ですか？

ありがとう

4

2 に答える 2

1

ASP.net MVC では、サービス指向アーキテクチャを利用し、バックエンドに MVC を引き続き使用できます。フロント エンドは HTML に対応し、javascript を使用して (フロント コントローラー)、SOA を使用してバックエンドに接続します。バックエンドのメッセージ パッシング (JSON) は、サービスを管理するための MVC アーキテクチャを持つことができます

于 2013-03-11T20:38:17.200 に答える
1

それはすべて依存します....

もちろん、JavaScript 内から MVC パターンを使用できます。MVC アプリケーションをサービス指向アーキテクチャーにフックすることもできます。

問題は、「ページをどこで構築するか」、つまりフロントエンドかサーバー側かということに帰着すると思います。

ブラウザーでページを作成する利点は明らかです。多くの重い作業がクライアントで発生するため、より簡単にスケーリングできます。さまざまな興味深い方法で構成できる疎結合サービスを作成する必要があります。

欠点はおそらくもう少し微妙です。ほとんどの検索エンジンは JavaScript を実行しないため、サービスによってレンダリングされた HTML が認識されない可能性があります。ブラウザーの数が増えるにつれて (スマートフォン、スマート TV など)、この種のアプリケーション ロジックのテストは非常に困難になる可能性があります。実際には、JavaScript に入れたいビジネスおよびアプリケーション ロジックの量に制限がある可能性があります。ダウンロード時間と実行時間が問題になる可能性があり、開発チームの多くの規律が必要です。ページのロジックによっては、サーバー上でページを構築するときほどキャッシュできない場合があります。

サーバー側のページ構築の利点も明らかです。確立されたライブラリとフレームワークを活用できます。ページはブラウザまたは CDN にキャッシュできます。サーバー上でビジネス ロジックやアプリケーション ロジックをテストすることで、すべてのデバイスで動作することを確信できます (ただし、ユーザー インターフェイスは壊れる可能性があります)。サーバーで生成されたページをサーバー上で構築するときに、さまざまな形式 (HTML バージョンや RSS バージョンなど) で公開する方がおそらく簡単です。

サーバー側のページ生成の欠点には、最初から設計しない限り、さまざまなコンポーネントを簡単に分解して再利用できないことが含まれます。Web アプリケーションが多くのサービスに依存している場合、バックエンド コードがその役割を果たしていない可能性があります。

于 2013-03-11T20:55:31.010 に答える