ビューモデルでのビジネスオブジェクトの使用

再利用可能なビジネスオブジェクトを使用する場合、ビューモデルを構築する際のベストプラクティスとは何ですか？

呼び出すオブジェクトを使用して、Builderビューモデルを構築します。ビューの各論理ユニット（オーダー、ユーザーなど）ごとに1つのビルダー。ここで、各ユニットにはさまざまなビューモデルを含めることができます（オーダーにはサマリー、オーダーラインなどが含まれます）。

ビルダーは、ビューモデルを構築するために、1つ以上の標準ビジネスオブジェクトを介してデータをプルする場合があります。

ビューモデルでビジネスオブジェクト/モデルを使用する場合のベストプラクティスとは何ですか？

アプローチ1

ビューモデルでビジネスオブジェクトの使用を許可しますか？

//Business object in some library
public class Order
{
    public int OrderNum;
    public int NumOrderLines;
    //...
}

//Order builder in website
public class OrderBuilder
{
    public OrderSummary BuildSummaryForOrder(int OrderNum)
    {
        Some.Business.Logic.Order obOrder = Some.Business.Logic.GetOrder(OrderNum);
        //Any exception handling, additional logic, or whatever

        OrderSummary obModel = new OrderSummary();
        obModel.Order = obOrder;

        return obModel;
    }
}

//View model
public class OrderSummary
{
    public Some.Business.Logic.Order Order;
    //Other methods for additional logic based on the order
    //and other properties
}

アプローチ2

ビジネスオブジェクトから必要なデータのみを取得する

//Business object in some library
public class Order
{
    public int OrderNum;
    public int NumOrderLines;
    //...
}

//Order builder in website
public class OrderBuilder
{
    public OrderSummary BuildSummaryForOrder(int OrderNum)
    {
        Some.Business.Logic.Order obOrder = Some.Business.Logic.GetOrder(OrderNum);
        //Any exception handling, additional logic, or whatever

        OrderSummary obModel = new OrderSummary()
        {
            OrderNum = obOrder.OrderNum,
            NumOrderLnes = obOrder.NumOrderLines,
        }

        return obModel;
    }
}

//View model
public class OrderSummary
{
    public int OrderNum;
    public int NumOrderLines
    //Other methods for additional logic based on the order
    //and other properties
}

私は両方の利点と欠点を見ることができますが、受け入れられたアプローチがあるのだろうか？アプローチ1では、モデルの周りにコードの重複はありませんが、ビジネスロジックへの依存関係を作成します。アプローチ2では、ビューに必要なデータのみを取得しますが、モデルの周りにコードを複製します。

オプション1は、ドメインモデルとビューの間に密結合を作成します。これは、モデルが解決するように設計されているビューの問題に反します。

ビューモデルが「変更する理由」は、ビュー自体が変更された場合です。ビューモデルにドメインモデルオブジェクトを配置することで、変更する別の理由を導入しています（たとえば、ドメインが変更された）。これは、単一責任原則の違反を明確に示しています。変更する2つ以上の理由があると、多くのメンテナンスを必要とするビューモデルにつながります。おそらく、ドメイン/ビューモデル間での複製のメンテナンスコストよりも多いでしょう。

私は常にアプローチ2を提唱します。ビューモデルはドメインモデルオブジェクトと非常によく似ている場合がありますが、ドメインモデルオブジェクトと同じである場合もよくあります。

コードの重複を避けるため、オプション1をお勧めします。それでおしまい。

ドメインモデルが大幅に変更された場合、ビューを変更する必要があることはほぼ確実です。オプション2では、ビューモデルとビルダー、およびビュー自体を変更する必要があります。そのようなことは、保守性にとって絶対的な毒です。ヤグニ。

別のビューモデルを持つことのポイントは、ビジネスモデルとは別に、ビューでのみ意味のある状態（現在選択されているタブなど）を保持することです。ただし、ビジネスデータ自体は複製するのではなく、再利用する必要があります。

原則とマントラは、デザインを導くために時々貴重です...しかし、ここに私の実用的な答えがあります：

ビューモデルがJSONまたはXMLにシリアル化されることを想像してください。ドメインモデルをシリアル化しようとすると、テキストの恐ろしい混乱に陥り、循環参照やその他の問題が発生する可能性が高くなります。

ビューモデルの目的は、ドメインモデルをグループ化してビューがそれらを消費できるようにすることではありません。代わりに、ビューモデルはビューの完全にフラットなモデルである必要があります...画面上で実際に見ているものです。ビューロジックは、ビューモデルに存在するデータの構造化にのみ関係する必要があります。

理想的には、ビューモデルはほぼ完全に事前にフォーマットされた文字列で構成される必要があります。考えてみてください。C＃、Javascript、Objective-Cなどでフォーマットロジックを実行するのにこだわっているので、ビューモデルにDateTimeや小数も必要ありません。