Eclipse SDK 4.x基于E4孵化器项目，是新一代构建基于Eclipse的工具和富客户端桌面应用的平台。它使得开发和组装基于Eclipse平台的应用和工具要更加容易。第一个版本（4.0）发布于...

必须得支持一下！

需要安装Web项目的插件，用MyEclipse的就行

这个问题好。应该先看看《如何阅读一本书》，里面讲了怎么阅读科技书籍

public static IEnumerable<int> Except(IEnumerable<int> list1, IEnumerable<int> list2) { foreach...

大家插入代码的时候用代码插入插件或者格式化一下不好么？ 你得确定你的dagaGridView1有几列。form4.dataGridView1.Columns[1].ToString()这里要找的是...

from room in GetRooms() select room.RoomID + "号房间（床位：" + room.BedNum + "）"; GetRooms返回IEnumerable<...

问题没有描述清楚，你使用的是什么数据访问组件？ADO.NET？LINQ to xxx？还是什么？ 另外，根据主键删除，与将guid转换为int或string没有任何关系，guid也可以根据主键删除。

参考：http://stackoverflow.com/questions/251391/why-is-lockthis-bad FYI...

引用

bandy：

引用

廁所里的燈：支持楼主啊！楼主可以和官方合作下啊！

谢谢各位的支持
我也觉得官方可以考虑开放几个简单的接口，然后让园友来制作各个移动平台的APP,利己利民啊

这个博客园的确应该考虑啊

不错，支持一个！

加油啊，MVC的书确实太少了

@King.cs
可空类型可以作为字典的键，只是说它们的相等性规则和其他类型（比如string）是一致的，没有特殊的地方，所以才可以作为键。但字典的键是不能为null的，否则就会抛出ArgumentNullException，这是Dictioinary的Add方法的规定。

@我想我是风
你说的，属于接口和抽象类的比较问题，抽象类在这里比接口要好，因为接口如果修改，需要更改所有实现类，而抽象类则不必。但不属于抽象与具体之间的优劣啊

@我想我是风
想问一下，对于服务类或者数据访问类，您的团队通常设计的都是返回接口吧？比如public IUserRepository UserRepository，然后在服务类里调用，为什么不返回UserRepository，为什么这样更灵活、耦合性更低，我想您是知道的吧。

@我想我是风
做个类比嘛，即便返回的不是私有类而是公共类，也是接口更好，不是吗

引用

我想我是风：事实上，在API的修改上，一般都是越修改越返回具体的类型，除非是一开始就设计错误了。

仍然无法认同，如果一开始设计得比较抽象，很可能不需要修改

引用

我想我是风：Where、Select、OrderBy，返回的是接口，是因为他们输入的就是接口，而且内部只是做了一些公式的转换，对IEnumerable本身没有任何操作，让他如何返回更具体的Enumerable？内部可能压根就没有new过Enumerable呀。

怎么没有new过啊？实际的返回值都是class啊

引用

我想我是风：
.NET升级，恰恰是因为只是增加类，而没有修改API接口，所以你才不用修改大量代码啊。
====
这就是api的设计原则呀，api升级，另外用一个类来代替原来的类，而不是直接修改，这样调用者就不会有问题了，调用者愿意的话，手工升级，使用新的版本不是更好。

其实我一直认为，项目的类库也是API，也应该严谨、合理地设计，而不是两个小组互相商量互相扯皮互相妥协的结果。

好修改了。...

其实就设计问题而言，不可能有统一的答案，更抽象也好更具体也罢，我们所讨论的不过是一个通用的指导原则。实际一些，是应该TDD+重构，直到找到最符合需求的设计。不知二位是否同意。

方法里实现，而不是在where，select里实现的。1. 您的回答没错，也刚刚好回答了@CodeBlood 关于“ToList方法为什么不返回IEnumerable”的反问。
2. Where、Select、OrderBy，尽管返回值不尽相同，但都返回的是接口，不是具体的某个Enumerable.Iterator<T>类。只有这样的设计，才使得LINQ如此优雅灵活。...

@我想我是风
可能上面没说清楚，这里再补充一下。
万一API修改了之后，返回了其他的只读集合，但是这个新的集合很可能不包含ReadOnlyCollection的某个方法，这样调用代码很可能面临修改了，对不对？
不过微软几乎没有这样的设计，因为他们在这种时候都提供了抽象的API。
比如LINQ的Where，返回的是IEnumerable<T>，但其内部返回的则是WhereXxxIterator<T>，如果返回值过于具体，LINQ很有可能无法像现在这样易于扩展，伸缩性强。

和不负责任。

引用

我想我是风：
DotNet升级，我都是自己改代码，改引用的库，而不是骂微软为什么又增加了这么多类

.NET升级，恰恰是因为只是增加类，而没有修改API接口，所以你才不用修改大量代码啊。
还拿之前的ReadOnlyCollection来举例，如果设计者的某个API返回ReadOnlyCollection，您觉得您只需要IEnumerable，所以声明变量时使用的是IEnumerable。但设计者怎么可能保证所有的用户都像您一样有

List。

引用

CodeBlood：
输出要具体也很明显：
尽量提供更具体一点的信息，以便更多的调用者都能使用这个方法

引用

我想我是风：
应该依赖接口或上层类，为什么你的设计理念却是去讨好底层类呢？

不知道是你们没明白还是怎么，API的返回值尽量抽象，才是更严格

;T>中的操作，那么你就应该将返回类型设置为List。

照例说ＡＰＩ的调用不应该对方法的返回值作任何类型转换，比如返回值类型IList<T>，你不能将其转换成Ｌｉｓｔ<T>...完全同意！...

引用

CodeBlood：
顺便说一句，在不影响代码逻辑的情况下，实际上返回IList这个方法是完全没必要存在的，因为ToList已经能胜任它的工作了，而且调用方得到的是更加具体的实例类型，能够做更多的事

这句话我是没法认同的，设计者希望用户如何操作，用户就应该如何操作，希望他们仅使用IList，就应该返回IList，用户得到IList。用户也尽量不要强制转换，否则一旦API有修改，代码还是被破坏了。

@我想我是风
返回值越具体越好，这显然不符合工厂模式啊。我倒不是非要去套用什么模式，但是对于API的设计者，对于这个方法是干什么用的，应该有自己的计划。不能留给调用者自己去判断取舍。比如一个方法返回了IEnumerable<T>，但内部实现时返回了ReadOnlyCollection，以后API升级时，还可以改成其他实现。但如果一开始就返回ReadOnlyCollection，以后想改变实现，除非提供一个新的方法，否则如何不影响调用代码？

@横竖都溢
牛逼。

@河蟹社会
挑选一个自己喜欢的领域钻研下去喽，既然你学过JavaScript，不妨就这个领域深入下去，现在前端是最吃香的……