WCF Webサービスとデータベースからの取得 - 既存のasp.netサービスレイヤーを使用しますか？

Question

私は、web.apiを使用してWCFサービスプロジェクトに取り組み、既存のasp.net mvc Webアプリケーションのモバイル版のデータを公開し始めました。

これまではWCF web.api getting started tutorialを使用して、ServiceContractで作成された偽のデータを使用して何かを実行しました。サービス契約は、次のようになります

：

[WebGet(UriTemplate = "")] 
    public IQueryable<Workspace> Get() 
    { 
     //I want to use our existing service layer like this: 
     //WorkspaceService service = new WorkspaceService(); 
     //service.ReturnAllWorkspacesByUsername("mary"); 

     //this is fake data for testing 
     var workspaces = new List<Workspace>() 
     { 
      new Workspace() {Id = new Guid(), Title = "Implement WCF Web Services"}, 
      new Workspace() {Id = new Guid(), Title = "Add APIs to WebService"}, 
      new Workspace() {Id = new Guid(), Title = "Map Routes"}, 
      new Workspace() {Id = new Guid(), Title = "Expose Resources"}, 
     }; 
     return workspaces.AsQueryable(); 
    } 

私は最高の既存のサービス層とドメインモデルを使用することができますどのように、可能な限り既存のMVCアプリケーションを使用したい、またはそれがベストプラクティスですない？サービスを分離する方が良いですか？

誰でもこのためにいくつかの初心者向けのチュートリアルを教えてもらえますか？

おかげで、 甲斐

Answer 1

は、私は、共通のプロセス内のビジネス・ロジック層を持っていることを好みます。 DTO（データ転送オブジェクト）は、レイヤー間で通信するために使用されます。データアクセス層がEFに基づいている場合、私はDTOとしてPOCOエンティティを使用することを好みます。さて、外部アプリケーションや異なるUIのために、私は別のサービス層を構築します。プロセスBLとDTOでデータを取得するために同じものを使用します。しかし、私はサービスのための別々のデータコントラクトクラスを持つことを好みます。

分離の背後に論理があると、サービスAPIが状態のないチャンクの多い対話に基づいている一方で、BLレイヤAPIがよりチャット（インプロセスレイヤ）になる可能性があります。限られた機能やさまざまなAPIをサービスを通じて公開することができます（外部アプリケーションによってサービスが使用されるという根本的な理由から）。また、DTOを& DataContractにすることもお勧めします。両方が異なる方法で、異なる時に変更される可能性があるからです。データコントラクトの変更は、DTO（またはドメインオブジェクト）には適用されないのに対し、制御およびバージョン管理が必要です。

モバイルUIは、サービスを使用する必要はなく、インプロセスBLレイヤーに直接依存します。これは元のMVCアプリケーションが階層化されたアプリケーションである場合に可能です。

また、WCFサービスからIQueryableを返すことは意味がありません。必要に応じてオブジェクトの配列を返すことができ、クライアントアプリケーションはIQueryableにキャストできます。