私はいくつかのプロジェクトに取り組んできました。そこでは、インターフェイス プロパティの変更可能性をほとんど、またはまったく公開しないインターフェイスに非常に厳密にコーディングしています。次に、オブジェクトを任意の方法で変更して返す任意の機能を提供するクラスを作成していることに気付きます。
次に例を示します。
public interface IOlapCube
{
String CubeName {get;}
IEnumerable<IDimension> Dimensions{get;}
IEnumerable<IMeasure> Measures {get;}
IEnumerable<IMeasureGroup> MeasureGroups {get;}
}
public class OlapCubeRW : IOlapCube
{
public String CubeName {get;set;}
private List<IDimension> _dimensionList;
public IList<IDimension> Dimensions{get{return this._dimensionList;}}
IEnumerable<IDimension> IOlapCube.Dimensions{get{return this.Dimensions;}}
//... similar for the rest
}
これはDTOですか？このクラスはどこで定義すればよいですか? IOlap キューブと同じアセンブリにする必要がありますか? もしそうなら、それは同じ名前空間にあるべきですか？私は、IOlapCube を使用するいくつかのプロジェクトが RW クラスの恩恵を受ける可能性があることを発見しており、各プロジェクトで同一の内部クラスを再実装するのは嫌いです。これらのクラスは、任意の派生クラスを作成してインターフェイスで参照できる単体テストにも役立ちます。たとえば、各インターフェイスには関連付けられた IEqualityComparer があり、単体テストでは、希望する任意の形状の 2 つのオブジェクトを作成して比較できる場合、かなり単純です。
これらは通常、エンティティの編集にも使用されます。エンティティをフォームに渡して、これらのオブジェクトの 1 つにコピーさせることができます。その後、フォームはオブジェクトを任意に変更でき、 bool OlapCubeValidator.IsValid(IOlapCube cubeToValidate); のような外部クラスで検証できます。検証に合格した場合は、変更をエンティティにコピーして戻します (おそらく、現在有効であることが保証されているこの RW クラスを介したエンティティ プロキシ)。
クライアントがこれらのいずれかをスピンアップして使用するべきではないように見えるため、IOlap と同じ場所に配置するのは間違っているように感じますが、外部で検証を実行できれば問題はないと思います。この特定のプロジェクトは会社の内部であるため、悪意を心配する必要はありません。怠惰なプログラミングだけです。これが公に利用可能なライブラリであった場合、何か変わるでしょうか?
編集 このインターフェイス階層 (IOlapCube > IDimension、IMeasureGroup、IMeasure > IHierarchy > ILevel > IMember) はメソッドやその他の機能を公開しないことに注意することが重要です。データのみを提供します (名前、子オブジェクト、IsVisible など)。IQueryable(T) ExecuteQuery(T)(ICriteria(T) criteria) のようなメソッドはありません。検証と等値の定義は、外部インターフェイス (IEqualityComparer など) の一部です。