ASP.NET MVCとREST API + Webページの使用のためのWCF

プログラムによるサービス指向の使用と人間の相互作用の議論は明確だと思います。

しかし、プログラムAPIと同じAPIで接続されたデータを使用するWebサイトの両方を使用するアプリケーションを作成する場合、ASP.NETのみを使用する方が有利でしょうか？

ASP.NETとWCFを統合して同じアプリケーションで動作させるのはどれくらい簡単ですか？

— Xster
ソース

ASP.NET/MVCとWCFの両方を活用する1つのアプリケーションを作成する限り、それは素晴らしいことではありません。WebAPIは問題を改善したかもしれませんが、同じアプリでWCFとMVCを使用していたことを知っている1つのプロジェクトでは、同じ概念を表す2つの異なるモデルセットを維持することになりました-1つはWCFコード用、もう1つはMVC用コード。2つのモデル間で物事を変換するために記述しなければならないすべてのマッパーを想像できます。

これが発生した理由の一部は、MVCがこれを必要としないのに対し、WCF要求および応答オブジェクトには[DataContract]で、そのプロパティには[DataMember]で注釈を付ける必要があることです。一方、慣用的なMVCでは、WCF DataContractsとは異なる目標を持つViewModelが必要になります。もちろん、ドメインオブジェクトの完全な2つのセットの使用は、WCFとMVCの競合よりもConwayの法則に関係している可能性がありますが、WCFとMVCには出力と入力に関して異なる目標と要件があることを指摘する価値があります。

個人的には、特に複数のクライアントが必要な場合には、シンプルだが強力なサービス指向のバックエンドAPIを開発することに部分的に取り組んでいます。BackboneJSやKnockoutJSなどを使用してアプリケーションコードを作成することで、有能な開発環境が可能になります。次に、選択したマイクロMVCでバックエンドを使用してWebアプリを構築するか、モバイルクライアントで使用できます。パートナーも同じAPIをリモートで使用できます。

提案

WebAPIまたはService Stackのいずれかが、バックエンドAPIを構築するのに適している可能性があります。過去数か月間使用してきたService Stackをお勧めします。WCFの優れた代替品であることがわかりました。現在、ブログでサービススタックに関するチュートリアルシリーズを書いています。

サービススタックを管理するグループは、フレームワークを使用して、クローンのようなStackOverflowを開発するサンプルアプリケーションを投稿しました。これは、特に説得力があると思われる開発パターンを示しています。これには、MVC Webサイト、モバイルアプリ、またはその他のあらゆるものによって簡単に消費されることを想像できる、単純なモデルベースのサービスバックエンドが含まれます。ServiceStackの設計目標は、クライアントとサーバー間の結合を減らすことにつながるパターンを明確に奨励しています。アイデアは、GetCustomersInRegionWithSearchTerm(int regionId, string searchTerm)メソッドの数を減らすなどの呼び出しでチャットAPIを避けることです。次のように、サービススタックに同じものを実装できます。

[Route("/customers", "GET"]
[Route("/customers/search/{SearchTerm}", "GET"]
[Route("/customers/region/{Region}", "GET"]
[Route("/customers/region/{Region}/search/{SearchTerm}", "GET"]
public class Customers 
{
    public int? RegionId { get; set; }
    public string SearchTerm { get; set; }
}

public class CustomersService : Service
{
    public object Get(Customers request) {
        // handle request
        return new CustomersResponse();
    }
}

利点は、私の目には、代わりに多く、別の方法の多くの上にビジネスロジックの広がりを持つことでGetCustomersInRegionWithSearchTerm(int regionId, string searchTerm)、GetCustomersInRegion(int regionId)、GetCustomersWithSearchTerm(string searchTerm)、GetCustomers()、それは一つの場所ですべてです。これにより、コードのメンテナンス性が向上します。

偶然にも、Stack Exchangeは元のService Stack作成者を雇いました。彼は引き続きService Stackプロジェクトに積極的に取り組んでいます。

私は特定の事柄のメッセージキューが特に好きです-WCFはこれを許可しますが、WebAPIは許可しません。ServiceStackでは、MQを介して同じWebサービスを呼び出すことができます。詳細については、次のRedis MQホストを参照してください：github.com/ServiceStack/ServiceStack/wiki/Messaging-and-redis

— カイル・ホジソン
ソース

注：ServiceStackでは、MQを介して同じWebサービスを呼び出すことができます。RedisMQ

— mythz

素晴らしいありがとう@mythz！知りませんでした。

— カイルホジソン

しかし、mvc4はWeb APIルートに行くようです...それは「公式にスポンサーされた」フレームワークになりませんか？

— Xster

過去2年間、「公式にスポンサーされたフレームワーク」（WCF pre WebAPI）に取り組んだ後、これは私の選択基準の一部ではなくなりました。それは、WebAPIが良いか悪いかということではなく、私はまだ試していません。ServiceStackは私の問題を解決しています。

— カイルホジソン

ここでは明白ですが、ViewModelsとWCFサービスからの応答オブジェクトは、完全に2つの別個のものです。ViewModelは、データのサブセットのみ、またはさまざまなソースからのデータを組み合わせたものです。ViewModelに異なるオブジェクトのセットを持つことは、MVCに必要なものとまったく同じであり、データの取得元（WCFまたはその他）は重要ではありません。また、オブジェクトタイプ間のマッピング用のAutomapperがあり、X.Name = Y.Nameボイラープレートコードをすべて保存します。

— オズ

@tzerbはIMOに正しく答えましたが、その答えを拡張したかったのです。現在ベータ段階にあり、OSSプロジェクトであるASP.NET Web APIは、最も探しているフレームワークです。

製品の簡単な説明は次のとおりです（ASP.NET Web APIページから引用）。

ASP.NET Web APIは、ブラウザーやモバイルデバイスを含む幅広いクライアントに到達するHTTPサービスを簡単に構築できるフレームワークです。ASP.NET Web APIは、.NET FrameworkでRESTfulアプリケーションを構築するための理想的なプラットフォームです。

Web APIを使用するために使用するクライアントアプリケーションについては、ASP.NETアプリケーションである必要はありません。JavaScriptを使用して、静的HTMLページでAPIを使用できます。これは、jQueryなどの便利なJavaScriptライブラリを使用して簡単に実行できます。

一方、ASP.NETアプリケーションのサーバーサイトでAPIを確実に使用できます。Web APIプロジェクトでは、HttpClientと呼ばれる新しいHTTP .NETクライアントAPIも導入しました。これにより、HTTPサービスを簡単に利用できます。

一般的に、開始するのに役立つリソースのセットは次のとおりです。

ASP.NET Web API入門-チュートリアル、ビデオ、サンプル

プロジェクトはまだベータ段階であることに注意してください。Henrik F Nielsenのブログで、プロジェクトの最新の未リリースの更新に関する情報を投稿することをお勧めします。プロジェクトのソースコードおよびASP.NET Web Stackプロジェクト内の開発フローにアクセスできます。

— ツベルク
ソース

現在の指針は、RESTにWCFの代わりにMVC Web APIを使用することだと思います。 http://stephenwalther.com/blog/archive/2012/03/05/introduction-to-the-asp-net-web-api.aspx

開発モデルはかなり近く、WCFの場合によっては厄介な構成をバイパスします。

— ツェルブ
ソース