好像和static没关系啊，个人认为是引用的问题 Bug继承一个IClone接口就搞定了啊

非常好，要是再加点iis7的图 理解的更快了。。 不过最终ok了 哈哈

我写 了下面的代码还是不行 Employee deleteEmp = HrDB.Employee.SingleOrDefault(e => e.EmpID == id); HrDB.Employee.Attach(deleteEmp); HrDB.Employee.DeleteOnSubmit(deleteEmp);

路过

坐沙发等人来拍砖！

从楼主态度可以看出，楼主不配称呼老鸟，顶多称“鸟”，而且年龄不大，教养欠佳，不懂得承认错误，不懂得全面分析错误，而只是为解决眼前问题而解决，不是为彻底解决而解决~像你这种人，见多了~

呵呵自称老手，到底有多老！！！

这代码破得，哎

@黑羽飘舞
多谢指点，暂时先解决速度问题，呵呵，new对象只会占用内存、和CPU存取对象时间。这部分我还会再进行优化的。由于急，只能暂时先这样了。谢谢！

这种方式只是暂时解决了返回值问题，并没有完成优化的任务，这种做法只能使性能更糟糕，毕竟是需要每次都去new一个bug对象。

最好的做法是优化流程，将变化与非变化隔离开来。此例中的BugCount玩全可以单独写一个static变量来使用

@Falepose
@AnsonWu
嗯，实际中当然不会这样去写，在此我只是想把最内在的东西展示出来，让资历浅的人去明白原理。

@yeml
嗯，你这方式也不错的。只是我死脑筋，一根筋到底了

楼主,这不是一个BUG,
这个特性用在缓存上用方便.
详见刘俊民的Opanlab.Framework中Cache部分.
炉火纯青的大侠之作.

@大同
谢谢理解！只是方式太笨了，在这藏龙卧虎之地容易遭人鄙视，哈……

@炭炭
好吧，我把需求说出来吧。
拿bug管理需求来说吧，这样比较贴近我的代码。但不同的是，这次我改BugContents而不是BugCount。

假如我有一个Bug管理表，这个表一开始会初始化一些数据。然后呢，有多人维护这个表，怎么维护呢，每个人根据自己当前遇到的Bug去修改BugDictionary中对应BugId的BugContents字段，这个BugId我们且将其做为Bug类型来对待。具体如何呢，就是比如我当前遇到一个bug，我根据这个bug类型从BugDictionary取出原始Contents，在其基础上修改，但不能改变BugDictionary中原始的Contents，也就是说，把BugDictionary当作原子数据。在其基础上衍生不同的版本。

不知朋友明白了没有。

@白发先生
写这篇文章我就知道会招骂，会有人看不下去，这也怪我太忙，写的也太匆忙，没有交代好上下文，但也有不少朋友能明白我的需求，或许他们也曾经遇到过这个问题，或许他们也希望有人提出来以警醒同行！

@代码优化
写的比我好，呵呵，我也觉得那么写有点儿别扭，谢谢！

呵呵，这个跟是否static没关系

楼主的的设计有点问题，既然不想改变字典里的那个bug对象的count，那这个count就不要放在bug对象里面，
应该做另外一个字典，专门保存bugid 和该id对应的bug出现的次数

tempBug.BugId = bug.BugId;
tempBug.BugTitle = bug.BugTitle;
tempBug.BugContents = bug.BugContents;
tempBug.BugCount = bug.BugCount;
tempBug.BugCount++;
可以考虑来个浅拷贝。。你这样一个一个拷贝，字段多了不是会死人？？

建议楼主好好补补基础知识，真的跟static没什么关系。。。