1

web.apiを使用してWCFサービスプロジェクトの作業を開始し、既存のasp.netmvcWebアプリケーションのモバイルバージョンのデータを公開しました。

これまで、このWCF web.api入門チュートリアルを使用して、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アプリケーションを可能な限り使用したいのですが、既存のサービスレイヤーとドメインモデルをどのように最適に使用できますか、それとも使用しないのがベストプラクティスですか？サービスを分離する方が良いですか？

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

ありがとう、カイ

4

1 に答える 1

0

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

分離の背後にある論理は、BLレイヤーAPIは（インプロセスレイヤーである）よりおしゃべりになる可能性があるのに対し、サービスAPIはステートレスの分厚い相互作用に基づくということです。制限された機能や異なるAPIをサービスを介して公開する場合があります（サービスは外部アプリケーションによって使用されるという印象があるため）。また、DTOとDataContractは、異なる方法で異なる時間に変更される可能性があるため、別々にすることをお勧めします。データコントラクトの変更は制御およびバージョン管理する必要がありますが、DTO（またはドメインオブジェクト）には適用できない場合があります。

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

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

于 2011-07-07T05:45:59.730 に答える