1.从封装角度看。这样的方法签名，表达能力不强，没交代清楚输入，调用者需要了解被调用代码细节，才能知道需要给哪些属性赋值。如果不同程序集，不同人员一同开发会有不小沟通障碍，一旦被调用方法参数有变要通知调用方，否则可能出现bug。
2.从接口角度看。基于第一点，很难形成接口，因为接口功能之一是定义输入输出的规范。
3.从维护角度看。
首先，代码是你自己写的，自然觉得问题不大，但是如果别人来做代码的维护，单看调用不看被调用方法的代码细节，确实不知道怎么改。其次，如果被调用方法所需参数数量发生变化时，那么调用代码的对象实例的属性需要相应的新增和修改，这个做不到自动重构，需要查找引用，然后手工一个个改，可能存在漏改；如果不改，多余的属性赋值显然会影响以后阅读。如果是指明参数个数和类型，起码编译的时候可以报错。
4.从隐藏Bug角度看。基于第三点，如果被调用方法体内部对参数使用个数等的修改，然后，调用没有同步修改，可能隐含造成bug（方法体新增参数的时候，调用没有同步新增属性的赋值）。
5.从泛型编程角度看。这样子的设计，难用泛型来编程，因为你需要给具体类型的具体属性赋值后才调用方法。
如果按照这样的思路，我一般更倾向于使用实体类作为参数。例如：
//以下DAO
public IDAO<TEntity> where TEntity : EntitieBase, new()
{
Add(TEntity);
Update(TEntity);
}
public abstract class DAOBase<TEntity, TDataContext> : IDAO<TEntity>
where TEntity : EntitieBase, new()
where TDataContext : DbContext, new()
{
protected TDataContext dataContext;
public TDataContext DataContext
{
get { return dataContext; }
}
Add(TEntity)
{
DataContext.Add(TEntity);
TEntity.ID = Guid.newd.tos();
}
}
public class DaoUser : DAOBase<User, EFEntities>
//以下BO
public abstract class BOBase<TEntity, TIDAO>
where TEntity : EntitieBase
where TIDAO : IDAO<TEntity>
{
protected ICacheManager CacheManager;
protected ILogManager LogManager;
protected ITranstionManager TranstionManager;
protected <T>ServiceLocator
{
//ioc容器
}
private TIDAO dao;
public TIDAO Dao
{
get
set
}
Add(TEntity)
{
Dao.Add(TEntity);
}
}
public class BoUser : BOBase<User, DaoUser>
来源： <http://bbs.csdn.net/topics/390891258>