使用方法参数与对象属性之间的比较

在做数据访问组件的时候为了实现我最初的想法我直接定义与DomainModel CRUD相关的四个接口来实现对应的操作,代码如下:

public interface IInsertBroker<T> 
{
   void Insert(T domainModel);
}

public interface IDeleteBroker<T>
{
   void Delete(object id);
   void Delete(T domainModel);
}

public interface IUpdateBroekr<T>
{
   void Update(T domainModel);
}

public interface ISelectBroker<T>
{
   T Select();
   T Select(string propertyName,object value);

   IList<T> SelectCollection(string propertyName,object value);
   IList<T> SelectCollection(string propertyName,object value,int start,int count);
   
  
}

当定义完成后,我发现有一个问题,因为这里的删除操作只支持两种形式的删除,如果需要实现如:按对象的属性值进行删除,按对象的多个属性值进行删除,按不规则的条件进行删除,那每一个操作都需要对接口进行修改才能够完成相应的这些功能,并且这个问题在ISelectBroker和IUpdateBroker之中一样存在,如果这里需要支持新的条件那就需要更新这里的接口定义.看来这实在不是一种好的方法,那么怎么样将这个问题解决呢?
这里我想通过这个问题其实已经看到了一个潜在的对象的存在,那就是条件对象ICondition,如果我们将按属性删除,按多个属性删除等看作是多个条件那么这个问题不就解决了吗.
通过这种方法将接口进行重新的定义:

public interface IInsertBroker<T>
{
   void Insert(T item);
}

public interface IDeleteBroker<T>
{
   void Delete(T item);
   void Delete(object itemId);
   void Delete(params ICondition[] condtions);
}

public interface IUpdateBroker<T>
{
   void Update(T item);
   void Update(string[] propertyNames,object[] values,params IConditions[] conditions);   
}

public interface ISelectBroekr<T> {
   T Select(object itemId);
   T Select(params IConditions[] conditions);

   IList<T> SelectCollection(params ICondition[] conditions);
   IList<T> SelectCollection(int start,int count,params ICondition[] conditions);
}

这里就是将需要的参数直接通过方便签名传送过去,能不能够将每实现对数据的一种操作定义为一个接口，再由具体的数据库来实现这种接口呢，这样扩展需要支持的新的数据操作，只需要直接添加新的接口就行了，采用Command模式的方法，感觉好像这是一种不错的解决方法，如按这种思路需要实现前面的IDelete接口可能就需要重新定义为:

public interface IDeleteBroker<T>
{
  void Delete();
}

public interface IPkDeleteBroker<T> : IDeleteBroekr
{
   object PkValue { get;set ;}
}

public interface IAllMatchDeleteBroker<T> : IDeleteBroker
{
   T : Value { get;set;}
}

这里就需要分别定义三个接口来完成前面删除这一个接口实现的功能,这样做好吗?
如果这里修改一个方法的参数就需要重样实现一个接口,那么这个组件一定会进入到一个接口爆炸的问题上来。并且这样给客户代码看到的不是一个可能以简单设计，而是一个有很多接口很多类的一种，并且如果需要实现通用数据访问那就太困难了。想来想去还是第二种好。