5

ASP.NET | MVC 4 | C# | WCF

プレゼンテーション層 (MVC) からデータ層 (エンティティ) への仲介として WCF Web サービスを使用しています。MVC から Web サービスへのデータ モデル データの移動を簡素化するために、WCF でプロキシ クラスを使用することを考えました。残念ながら、これによりモデル内のプロパティの MVC 装飾が失われました。MVC ビューのモデルで使用するため、および WCF サービスへのトランスポート メソッドとして使用するための集中化されたクラスを作成する良い方法はありますか?

オプションとして自動マッピングが思い浮かびましたが、それには 2 つの同一のクラスが必要になると思います。MVC 側に 1 つ、WCF 側に 1 つ。クラスでプロパティが変更された場合、両側で変更を加える必要があります。

他の提案をいただければ幸いです。ありがとう！

編集:: 例

これは、レコードのテーブルを含むページのモデルです

public class ReconcileModel
{
    #region PROPERTIES

    public List<ReconcileItem> ReconcileItems { get; set;}

    #endregion

    #region CONSTRUCTORS

    public ReconcileModel()
    {
        ReconcileItems = new List<ReconcileItem>();
    }

    #endregion
}

そのテーブルの各レコードを表すクラスを次に示します。

public class ReconcileItem
{
    #region PROPERTIES

    public int ID { get; set; }
    public string Description { get; set; }
    public string LastLocation { get; set; }
    public string LastRead { get; set; }
    public string IntendenLocation { get; set; }
    public string PickId { get; set; }
    public string OEM { get; set; }
    public string LotNumber { get; set; }
    public string SerialNumber { get; set; }
    public DateTime ExpirationDate { get; set; }
    public string ReconcileReason { get; set; }
    public string RemoveReason { get; set; }


    #endregion

    #region CONSTRUCTORS

    public ReconcileItem()
    {
    }

    #endregion
}

上記のクラスの WCF コントラクト表現は次のようになります。

[DataContract]
public class ReconcileItem
{
    [DataMemeber]
    public int ID { get; set; }
    [DataMember]
    public string Description { get; set; }
    [DataMember]
    public string LastLocation { get; set; }
    [DataMember]
    public string LastRead { get; set; }
    [DataMember]
    public string IntendenLocation { get; set; }
    [DataMemeber]
    public string PickId { get; set; }
    [DataMember]
    public string OEM { get; set; }
    [DataMember]
    public string LotNumber { get; set; }
    [DataMember]
    public string SerialNumber { get; set; }
    [DataMember]
    public DateTime ExpirationDate { get; set; }
    [DataMember]
    public string ReconcileReason { get; set; }
    [DataMember]
    public string RemoveReason { get; set; }
}

このレコードを更新する場合、クラスは WCF サービスに送信され、適切なエンティティ フレームワーク クラスにマップされ、データベースに保存されます。転送を簡素化するために、このクラスを WCF プロジェクトに配置し、MVC プロジェクトで参照するだけでよいと考えました。その後、WCF と MVC の間でクラスをやり取りできます。また、WCF でクラスを更新すると、MVC に反映されます。これが中央集権化の意味です。

4

3 に答える 3

2

私の現在の雇用主では、投稿で説明した方法で WCF を使用しています。最終的には、WCF および MVC と通信するための DTO クラスと、UI 内でのモデル バインディングと検証のための MVC アプリケーション内の ViewModels を持つことになりました。

互いにほとんど重複しているクラスを持ち、それらの間でマッピングすることは苦痛であり、あるレベルでは間違っているように見えることに同意します。私が過去に読んだことから、私たちが行ったこと、そしてあなたがしなければならないかもしれないことは、ベストプラクティスです.

Adrian が上記で提案した、WCF によって重い処理のみが行われることに関しても同様に理にかなっています。今の仕事を始める前は、まさにそうでした。ビジネス ロジックのほとんどは、MVC アプリケーションによって直接参照されるビジネス レイヤー アセンブリに配置されました。実行時間が長くなる可能性のあるいくつかのプロセスについては、MVC アプリケーションが通信する、個別にホストされる WCF サービスを作成しました。

最後に、Web API と WCF のどちらを使用できますか? Web API は軽量であり、WCF バインディングなどに伴うすべてのオーバーヘッドなしで HTTP を利用します。さらに、Web API を使用すると、MVC アプリケーションが使用しているのと同じクラスを使用でき、Web API 内でモデル検証を利用することもできます。これは私が取り組んできたことであり、ますます一般的になっています。

それが役立つことを願っています!

于 2013-09-10T23:52:27.953 に答える
2

エンティティを引き続き使用できますが、ビュー モデルを作成し、代わりにこれらにデータ注釈を付けます。プロジェクトのどこに検証を配置するかについては、多くの議論があります。一般に、ほとんどの場合、UI で発生する必要があり、通常は他の場所でも発生する必要があります。これは決してうまくいかないので、集中化しようとすることは避けたいと思います（1つのサイズがすべてに適合することはめったにありません）。

ソリューション内に WCF レイヤーを組み込むことに関しては、非常に正当な理由がない限り、これを行うことは絶対に避けます。私はこの種の失敗を何度も見てきました。それは多くの悪影響をもたらします。私が扱った 2 つの商用ケースでは、エンドポイントが多すぎて、おしゃべりが多すぎます。エンティティにビジネス ロジックを配置し、それらのメソッドをネットワーク上で使用することができなくなり、メンテナンスが悪夢のようになり、十分なハードウェアと慎重な設計がなければ、単一のサーバーでホストされている場合、名前付きパイプを使用する必要が生じる可能性があります。必要な速度が得られますが、これは WCF を使用することで得られる分散型の利点を無効にします。

負荷の高い処理タスクは、他の場所でホストできるコンポーネントとして外部化し、より小さく簡潔なインターフェイスを介して通信することをお勧めします。実際には、画像処理、数学的および科学的アプリケーションを除けば、重いデータ処理は発生しません。

于 2013-09-10T21:58:16.507 に答える