2

私たちは、ウェブサイトをアップグレードする新しいプロジェクトをどこから開始するかを決めようとしています. 古いバックエンド システムを .NET にアップグレードしたので、TFS の統合、開発環境、テスト、Azure の統合、統合されたセキュリティ、適切なドキュメント、等

また、達成したいことは、Web ベースの API から始めて、最初は通常の Web サイトで、後にモバイル デバイスでも独自のサービスを利用することです。私たちは、WCF (OData 対応) データ サービスと、MVC4 に付属する新しい Web API を試してきました。

私の個人的な好みは、Data Services を使用することです。$select オプションなど、より多くの OData 標準が実装されているため、作成する API が非常にシンプルで非常に便利になり、使用するデータのみを要求するようにすることができます。クライアント、JSON、XML、およびおそらくすぐには使用しない他の形式で。

最初のプロジェクトは、データ サービスまたは Web API のいずれかを使用する Web サイトを実装することです。クライアント側からサービスを使用するには、どのフレームワークを調べる必要があります。理想的には、別のマシンから Web サイトを提供し、クライアントが Ajax (または JSONP) を使用して API に接続し、サービスから読み取るようにします (後の段階で CUD アクションも)。

新しい Web サイトを作成するために、一連のツールを購入したいと考えており、Telerik、DevExpress、および Ext.NET を評価しましたが、サイトで主張されているように、これらのサービスのいずれとも互換性があるようには見えません (しかし、おそらく私は行方不明です)。なにか）。独自の JavaScript を作成することは避けたいと考えています。

私の質問は次のとおりだと思います。

  • API のどの手法が優れているか、またその理由は? DataService はかなり古いようです。今後もサポートされますか? 評価すべき 3 番目のオプションはありますか?
  • 誰かが同様のプロジェクトを引き受けることを選択しましたか?あなたの経験を共有できますか?
  • Telerik、DevExpress、Ext.NET、またはその他のフレームワークのうち、クライアント側からこれらの API を使用するのに役立つのはどれですか?
  • WebForms または MVC を使用する必要があるのはなぜですか?
4

1 に答える 1

2

最近のプロジェクトでは、商用のサードパーティ ライブラリを完全に避けました - さまざまな理由から: オープン ソース ライブラリ (明らかな理由で GPL ではなく、主に BSD/Apache) と比較して感心していませんでしたが、私たちがやろうとしていたことの多くは非常に単純であり、既存のプラットフォームを学び、時間をかけてやりたいことができるようにするよりも、独自のプラットフォームを構築する方が簡単だからです。

バックエンド API には、WCF に対して記述された完全な RESTful サービスを使用しました。独自の POCO データ コントラクト オブジェクトを使用して純粋でシンプルな XML を返します。これは、独自のクライアントを複数の言語 (.NET、PHP、jQuery を使用した Javascript など) で非常に迅速かつ簡単に開発できることを意味します。ペストのような SOAP は避けてください。ただし、WCF が適切な RESTful な方法で動作するようになるまでにはかなりの時間がかかりました。プロジェクトを最初から行っていた場合、IIS に場合によっては、不必要に複雑になります (たとえば、私たちのサービスでは、アクセス制御に HTTP 基本認証を使用していますが、IIS はその中間に位置することを好みます)。次に、IIS と WCF がそれを明らかにする「ベース URL」にも問題があります。IIS の WCF は、使いやすさを向上させる必要があります。

クライアント側では、Javascript がサービスに直接接続できるようにするオプションがありますが、実際のパフォーマンスの向上は見られませんでした。最終的に、スクリプトが Web サイト独自の AJAX インターフェイスを介してすべてを実行するようにすることにしました。さらに、バックエンドのデータソースまたは API を公開することは、実装の詳細を明らかにすることであり、優れたソフトウェア エンジニアリングではありません。

上記の理由により、クライアント側のフレームワークを避けます。XHTML/CSS に精通している場合は、独自の Web ベースのウィジェットを簡単に記述して、それらがアプリケーション用に構築されていることを確認できます。ページ上に Telerik/DevExpress/etc コントロールを散りばめただけのアプリケーションが多すぎて、インポートされたすべてのクライアント側スクリプト ファイルとリソースが原因で、遅くて面倒な混乱が生じるのを見てきました。

WebForms は終わり、ASP.NET MVC が未来です。それに対して作成するコードは、よりクリーンで、整理され、一貫したものになります。「コントロール」、ライフサイクル、viewstate をすべて削除すると、すべてが簡素化され、多くの ASP.NET のブードゥー (Page_Load 後に追加されたコントロールに何が起こるかなど) が排除されます。二度と WebResource.axd を見たくありません (外出先でのクライアント側スクリプトのデバッグとカスタマイズが非常に困難になります)。

悪いニュースは、あなたやあなたのチームが「正しい方法」で物事を行った経験があまりない場合 (つまり、HTML のビジュアル デザイナーを使用しない、過度の DataBinding を使用しない、または単に<asp:DataGrid>ページ上で .あなたが悪い習慣を学ぶのに苦労します。

HTH。

于 2012-07-02T15:48:59.217 に答える