我参与了几个项目,我们非常严格地编写了接口,这些接口几乎没有暴露接口属性的可变性。然后,我发现自己编写的类提供了以任何方式改变对象的任意能力并将其返回。
以下是一个例子:
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,当我可以用我想要的任何形状构造两个对象并比较它们时,测试比较器的单元非常简单。
这些通常也用于编辑实体。我可以将实体传递给表单,并将其复制到其中一个对象中。然后表单可以任意改变对象,我可以使用像bool OlapCubeValidator.IsValid(IOlapCube cubeToValidate)这样的外部类来验证它。如果验证通过,则将更改复制回实体(也许实体代理通过此RW类,现在确保有效)。
将它们放在与IOlap相同的位置是不对的,因为看起来客户端不应该启动其中一个并使用它,但我想如果我可以在外部执行验证,它不会有任何损害。这个具体的项目是公司内部的,所以我们不必担心恶意,只是懒惰的编程。如果这是一个公开的图书馆,它会改变什么吗?
修改 重要的是要注意,该接口层次结构(IOlapCube&gt; IDimension,IMeasureGroup,IMeasure&gt; IHierarchy&gt; ILevel&gt; IMember)不公开任何方法或其他功能;它们只提供数据(例如名称,子对象,IsVisible,......)。有没有方法,如IQueryable(T)ExecuteQuery(T)(ICriteria(T)标准)。验证和相等定义是外部接口的一部分(例如,IEqualityComparer)。
答案 0 :(得分:0)
只要DTO仅用于保存数据(没有业务逻辑),如果将接口保持在同一个程序集或不同的程序集中就无所谓了。