3

当社の製品の1つには、複数のWCFサービスが含まれており、そのビジネスレイヤーはすべて、NoSqlデータベース（mongodb）へのアクセスを提供する同じデータアクセスレイヤーの上にあります。

  WCF   WCF   WCF
   |     |     |
   BL    BL    BL
   |     |     |
 Data Access Layer        <-- PageInfoResult currently defined here
         |
      mongodb

PageInfoResult各サービスには、データベースに直接格納されている特定のタイプ（）を受け入れるか返す1つ以上のメソッドが含まれているため、クラスPageInfoResultはDALでBsonシリアル化属性（mongodbの場合）とデータコントラクトシリアル化属性の両方で定義されます。 （WCFの場合）。

例：

[DataContract]
public class PageInfoResult
{
    [BsonId]
    [DataMember]
    public string PageUrl { get; set; }

    [BsonElement("status")]
    [DataMember]
    public int HttpStatusCode { get; set; }

    [BsonElement("score")]
    [DataMember]
    public int OurProprietaryPageScore { get; set; }

    [BsonElement("data")]
    [DataMember]
    public SomeOtherClass OtherData { get; set; }

    // ... other properties ...
}

したがって、具体的な質問は次のとおりです。

  1. 各WCFサービスを再定義してから、DALのデータモデルにグラフ化する必要がありますか、それともDALをモデルが定義される唯一の場所にすることができますか？
  2. 各サービスがDAL内の各モデルを再定義する必要がある場合、サービスモデルはデータモデルから継承する必要がありますか（またはその逆）？

より一般的な意味で：

  1. 非常に類似した（または同一の）サービスおよびデータモデルを定義するための適切なオブジェクト指向アプローチは何ですか？
  2. スキーマとスキーマレスデータベース（MsSqlとMongoDB）を扱う場合のアプローチに違いはありますか？
4

1 に答える 1

1

  1. データモデルとWCFコントラクトは、まったく異なる2つのものです。それらは同じであってはなりません！それらが同じである場合、サービス層はデータアクセス層に緊密に結合されています。

  2. 私の意見は「ノー」です。継承は、2つの間の密結合を意味します。

クライアントに正確に何を公開しているかという観点から、サービスレイヤーを考えるのが最善です。WCFデータコントラクトには、クライアントがサービスを呼び出すために必要な情報のみを格納する必要があります。

サービスレイヤーのデータコントラクトとデータモデルとの間の「変換」は、おそらくビジネスレイヤーで行われるはずです。さらに良いことに、ビジネスレイヤーは、データコントラクトとデータモデルの「コンシューマー」または「ユーザー」と考えてください。

繰り返しますが、それは私の意見ですが、完全に分離していると考えるのが最善だと思います。

編集:(コメントから）ソリューションのアーキテクチャを複雑にするだけの複雑なレイヤーを切り離して追加しようとすることがあります。私の答えとは対照的に、おそらく「それをシンプルに保つ」のでしょうか？その場合は、継承を行う必要はありません。うまくいく場合は、実行していることを実行してください。

于 2012-06-26T19:16:17.083 に答える