2

ここで明らかな何かが欠けている可能性があります...

しかし、IoCとctorインジェクションの栄光を理解することを学ぶにつれて、これをオブジェクトグラフのシリアル化と調整するのに苦労しています。2つのパターンは互換性がありますか？なぜ（またはなぜそうではない）？

次のようなものがあるとします。

public class Foo
{
    #region invariants
    private readonly List<IBar> _bars;
    private readonly Guid _id;
    #endregion

    public Foo( List<IBar> bars, Guid id )
    {
        _bars = bars.CannotBeNull("bars");
        _id = id.CannotBeNull("id");
    }

    public List<IBar> Bars { get { return _bars; } }

    //some other state I want serialized
}

public static class Ex
{
    public static T CannotBeNull<T>( this T obj, string paramName = "" )
    {
        if ( null == obj ) throw new ArgumentNullException(paramName);
        return obj;
    }
}

私は、コンストラクター注入によってクラスの不変条件を保護する鉄で覆われた安全装置が好きです。それは私のオブジェクトに彼らが常に彼らが必要とするものを持っているという確実性を与えます。不変条件の注入はリポジトリパターンと対立していますか？たぶん、ギャップを埋めるDTOレイヤーとファクトリパターンがどこかにあります...？

賢明なアドバイスを探しています...2つのパターンは互換性がありますか？なぜ（またはなぜそうではない）？

PS：IDeserializationCallbackについては知っていますが、「プライベート読み取り専用」の不変条件でどのように役立つかわかりません

4

2 に答える 2

5

そのトピックに関するMarkSeemannによる記事があります。境界では、アプリケーションはオブジェクト指向ではありません。要点は次のとおりです。境界では、アプリケーションはオブジェクト指向ではありません。ある種の変換（シリアル化など）が発生している場合、クラスの不変条件を保護することはできません。

于 2012-01-22T05:05:06.187 に答える
0

あなたの質問がリポジトリパターンと何の関係があるのか​​はっきりしていません。リポジトリをシリアル化する必要がありますか？

いずれにせよ、XMLシリアル化を使用すると、プロパティにセッターが必要になるという制限があります。あなたと同じように、私はコンストラクターに対してクラス不変を維持することを好むので、これも苦痛だと思います。.NetでXMLシリアル化を使用するのは単なる現実なので、選択の余地はありません（カスタムシリアライザーを作成できると思いますが、IIRCは面倒です）。

オプションがある場合は、プライベートメンバー変数をシリアル化できるバイナリシリアル化への切り替えを検討することもできます。私が見つけることができる最高の情報源はここにあります。

編集：私はあなたの質問にもっと直接的に答えると思います：パターン自体は対立していませんが、テクノロジーの実装（XMLシリアル化を使用する場合）はそれらを互換性のないものにします。

于 2012-01-22T03:13:07.693 に答える