今天突发奇想，如果说我们与数据库交互的代码有这么多相同的话，那为什么我不去封装一个公共方法来使用。后来研究了半天，发现只有泛型+反射机制去实现，可是朋友们说这样会导致整个网站运行缓慢甚至奔溃，请问，是这样吗？能帮我说明一下原因吗？
/// <summary>
/// update
/// </summary>
/// <param name="Model">修改实体</param>
/// <param name="where">条件</param>
/// <returns>成功为1失败为0</returns>
public static StringBuilder ReturnUpdateIsOK(T Model, string where)
{
try
{
StringBuilder sb = new StringBuilder();
if (ProtectIsShow(where, out sb))
{
sb.AppendLine("内含危险字符！");
return sb;
}
else
{
List<StringBuilder> sbuList = ValueFieldsAndParam(Model, "Update");
SqlParameter[] para = GetParas(Model);
StringBuilder strSql = new StringBuilder();
StringBuilder sbu = new StringBuilder();
strSql.Append("update " + sbuList[3] + " set ");
strSql.Append(sbuList[0]);
if (!string.IsNullOrEmpty(where))
{
strSql.Append(" where " + where);
}
else
{
strSql.Append(sbuList[4]);
}
int rows = DbHelperSQL.ExecuteSql(strSql.ToString(), para);
if (rows > 0)
{
sbu.Append("1");
}
else
{
sbu.Append("0");
}
return sbu;
}
}
catch (Exception ex)
{
return Common.ReturnException(ex);
}
}
------解决思路----------------------
其实你的想法很好~
接下来的问题~ 既然你能想到泛型+反射
那么你应该有能力想到怎么去测试这代码的效率
搜索一下： Repository模式
再学习一下ORM框架 EntityFramework
------解决思路----------------------
嗯，我上面不是针对 lz 的问题，而是针对某些过激的框架而言的。使用那些框架，只能让学生有几个月的新鲜感（因为学生的心目中没有质量概念），而项目经理则会因为调试问题而头疼。
你可以写一个反射代码，尽量控制在100行代码以内，我当然赞成你这样写！
但是你不要说你就是要替换掉人家整站的数据库操作代码。你在问题中的这种态度，是要不得的。你应该让同事们抽出百分之一的数据库操作代码，来试用你的代码。如果你自己也是这样想的，那么才能保证逐渐成熟地开发一个框架，而不会总想着“推倒重来”。
------解决思路----------------------
orm框架你可以使用ef
不用框架 基于ado.net有很多封装好的dbhelper或sqlhelper 其中也有复杂点的用到反射 你可以下载下来研究研究
------解决思路----------------------
其实用不着反射，你可以先做一个baseModel，其它所有的model从这baseModel进行扩展。
baseModel做成类似于Dictionary<K,V>,就OK了。
------解决思路----------------------
运行缓慢？别开玩笑了。。
这里不用反射的话真是太浪费了。。
这里通过反射获取到值，设置SqlParameter[] 和生成sql语句。。性能差都是毫秒级的，完全可以忽略。。
如果上百个类，是不是要写上百个这样的东西？这些地方不用反射很浪费。。这里完全可以牺牲那么毫秒级的性能来换取代码的可维护性。。
这样的代码没什么不好，我觉得是非常不错的