6

すべてのアプリケーションが Web プロジェクト (クラウドまたは Web サービスを使用する) と対話するという事実を考慮して、アプリケーション間でクラス モデルを共有する方法はありますか?

はいの場合、それを行うための最良の方法は何ですか?

Web サービスからのデータの送信/受信、シリアル化および逆シリアル化について、オブジェクトを手動で設定することなく簡単な方法でこれを行うにはどうすればよいですか?

このアプリケーションに関する情報は本当に役に立ちます!

4

6 に答える 6

6

一般に、このようなアプリケーション間でドメイン モデルを共有することはお勧めできません。アプリケーション間にハードな依存関係を作成しているためです。つまり、ドメイン モデルを変更するとすべてのアプリに影響し、Web、電話、およびデスクトップ アプリのリリースを同期する必要があります。 .

アプリケーションの種類ごとに特定の情報ニーズに合わせて調整された個別のモデルを作成することをお勧めします。これにより、もちろん複雑さが増しますが、私の経験では、他のシナリオと比較して管理しやすくなっています。

サービスの呼び出しに WCF を使用する場合、シリアル化の質問については不明です。問題はありません。処理されます。

ドメイン クラスの作成には、AutoMapper をお勧めします。AutoMapper は、いくつかのプロジェクトで使用して成功しています。名前に基づいてあるクラスから別のクラスに自動的にマップでき、例外を指定するだけです (つまり、フィールド名がマップされていないか、何らかのタイプの変換ロジックが必要でした) github の Automapper

于 2012-07-06T10:24:38.567 に答える
2

サーバー側ドメイン モデルをクライアント アプリケーションに配布せず、代わりに Web サービス プロキシ ジェネレーターを介してクライアント エンティティを生成し、AutoMap を使用してマッピングを行うことを提案する人もいますが、共有 DLL を介してエンティティがクライアントと共有されるアプローチに固執することを好みます。これにはさまざまな利点があります。

長所

  • 二重コーディングはありません。
  • プロキシ オブジェクトを実際のオブジェクトにマッピングしません。したがって、パフォーマンスの低下はありません。
  • サーバー側とクライアント側のエンティティでの二重検証の実装はありません。
  • エンティティ オブジェクトを参照するユーティリティ ライブラリを共有します。クライアント プロキシで生成されたエンティティ用にユーティリティ ライブラリを再度作成する必要はありません。これは大きな苦痛です。
  • 一度設計すれば、どこでも再利用できます。

短所

  • エンティティ ライブラリはプレーンなバニラ クラスでなければなりません。外部ライブラリへの参照はありません。
  • 既存のプロパティを削除したり、名前を変更したりすることはできません。

サーバーエンティティが変更され、クライアント側のコードが壊れることについて、いくつかの異論があることを理解しました。しかし、クライアントとサーバーを所有している実際の状況では、いつでも新しいバージョンをクライアントに出荷できます。そうしなくても、いつでもエンティティへの変更をバージョン管理し、新しいバージョンのエンティティを送り返す新しいサービスを導入できます。また、互換性が失われる可能性は低いです。プロパティを削除するか、既存のエンティティのプロパティの名前を変更した場合にのみ壊れます。それは通常、低い確率です。私の経験では、エンティティに新しいプロパティを追加することがほとんどでした。エンティティに新しいプロパティを追加しても、古いエンティティ DLL を持つ古いクライアントは引き続き機能します。SOAP ペイロードをデシリアライズすることもできます。

したがって、いくつかの短所はありますが、私の意見では、長所は短所を上回っています。そのため、すべてのエンティティを POCO として含むエンティティ DLL を常に持っており、それをクライアント アプリやサーバーと共有しています。

お役に立てれば。

于 2012-07-09T14:06:13.397 に答える
1

私が知っているいくつかのオプションがあります。

  1. Web サービスでモデルを定義します。アプリケーションがサービスへの参照を追加すると、モデル定義も取得されます。

  2. ファイル リンクを使用して、ドメイン ファイルを各プロジェクトにリンクします (現在、クライアントと完全な .net の間の不一致を解決するために、いくつかの魔法を使用してこれを行っています (オートマッパーまたはリフレクションを使用してローカル オブジェクトを設定します)。

  3. それぞれが参照する個別のプロジェクトでモデルをドメイン化しているか

于 2012-07-04T05:18:19.623 に答える
0

非常に無駄のないドメインプロジェクトを 1 つ作成することをお勧めします。これは、多くの手間のかかる作業を行いますが、プロジェクト タイプ (WPF、ASP.Net など) に共通のレイヤーを提供します。

Domainはすべての異なるタイプのプロジェクトで動作することを意図しているため、必要なすべてのプロジェクト タイプで使用できない名前空間をドメインに含めることはできません。これは困難です。

これに取り組むには、コンパイラ ディレクティブを介してドメインプロジェクトの拡張機能を提供するサービスプロジェクトを作成するか、サービスをプロジェクトの種類ごとに異なるプロジェクトを持つ名前空間にすることをお勧めします。(このように、Silverlight のみを出荷する場合、Services.SilverlightをDomainおよび Silverlight プロジェクトと共に出荷します。) これにより、コンパイラ ディレクティブの量が削減されます。

上記のプロジェクトを作成したら、他のすべてのプロジェクトのフロントエンドとアプリケーション固有のロジックの作成を開始できます。その後、auto-mapper またはその他のツールを使用して、(おそらく) ビューモデルをDomainのモデルにマップできます。

ドメインとサービスをすべてのコア ロジックの 1 つのレイヤーにすることで、後で必要に応じて他のプロジェクト タイプに拡張するのに役立ちます。

于 2012-07-12T19:56:36.143 に答える