以下转载自一个贴吧大神的回复：

=====================================================================

我写的C#多于Java，也更喜欢C#。

我一个同学说过“没有JDK文档的情况下，我没法写Java，但是没有MSDN的情况下，我照样写.Net的程序。”这话我十分赞同。因为Java太混乱了，很多不够合理的地方，没有文档的话，很多你想找的类，你不知道该去哪个包里找。而C#更接近于人的思维习惯。

说一个我跟别人说过很多次的例子。---你要在代码中获取系统当前时间。你会去哪里找？至少我的第一想法是去Date类、Time类或者DateTime类里找。我在Java里找了好久，最后发现在Calendar类里。。。而且Java下，这个从Calendar类获取的系统时间，要转化成Date、Time之类的东西才能在别处用，可是，印象中要从Date、Time类型的变量中提取int类型的小时、分钟神马的值，很麻烦，反而获取从19xx年1月1号开始的毫秒数很容易。但问题是，我获得这玩意之后可以干嘛？用它比较时间先后倒是不错。但是在C#下，你直接去DateTime类里，就能找到。DateTime类里有个属性叫Now。而且C#的DateTime类，可以很方便的获取小时、分钟什么的。

---

而且C#中可以重载运算符，直接用大于号、小于号就可以比较时间先后，用==就可以比较字符串。而Java里比较字符串非得用.equals()，很纠结呀。对于那些不习惯用==比较字符串的Java程序员，你在C#里也仍然可以使用.equals()。

---

记得有人跟我讲过这样一个事：微软专门请过1000个程序员，给他们n小时，写一个读写文件的程序。结束之后，经过微软统计发现，这1000人里大部分人首先想到去找File这个类。于是微软就在它的C#里，把File做成了个静态类，专门提供各种用于读写文件的方法。

---

泛型这东西是C#首先支持的。泛型这东西，可以大大降低强制转换的次数，降低错误转换的可能性。而Java似乎在JavaSE1.5（有可能是1.6，记不清了）才开始支持泛型。所以你在写Java的时候，有些第三方jar包，为了兼容这之前的java版本，里面的方法给你返回的是object类型的东西，需要你手动转换。

---

C#下的枚举也比Java安全。Java里面的枚举直接用int强制转换过去就行，你甚至可以在不知道一个int在枚举中意味着什么，就把它作为参数传进去。而C#里的枚举是强类型，不能随意转换。

---

C#下有很多用来降低程序员因为马虎出错的可能性的东西。比如参数的ref、in、out标记。加了in标记的参数，你在函数里就没法对它进行赋值了。防止程序员错误的向变量写入东西，降低bug率。而且在后期维护程序的时候，负责维护的程序员看到in标记之后，就知道这个函数无论怎么改，这个参数不要动。而加了out标记的参数，系统就会允许调用者传未赋值的变量进来。但是，不管这个参数传进来的时候有没有被赋值，系统会要求你首先对这个变量进行赋值才能使用。就是说，变量里任何已经存在的值你是没法使用的，必须要覆盖掉。而且如果方法里存在一个代码路径没有对这个参数进行赋值，系统会报错。这个也可以降低bug数量。加了ref标记的参数，对于引用类型的东西，比如类的实例，这个ref标记加不加没有区别。但是对于值类型的参数，比如int、结构体等，就可以以传引用的方式调用了。

---

C#下，集合操作远远比Java方便。尤其是有了泛型。C#下，几乎所有集合类型都可以转换成IEnumerable<T>类型，IEnumerable<T>可以用ToList()方法转换为List<T>，而且都可以用foreach来遍历。Java里，List是抽象类，我最初接触Java的时候，找了好久都不知道为什么new List()会出错。。。最后才知道要new HashSet()C#下的Linq、Lambda表达式可以很方便的对集合查询。

---

C#的好多集合类型、Collection类型，都可以用索引器。比如List<String>类型的strList，我们可以直接strList[i]来获取第i个元素。Dictionary<String,String>类型的someDict，我们可以直接用someDict[someKey]来获取某Key对应的Value。

---

C#里的属性是个化繁为简的好东西。Java里为了写一个JavaBean，你需要为每个属性写一个千篇一律的getXXX()和setXXX方法，而在C#里你可以简单的写String someProperty{get;set;}就行。get和set也可以单独限定private、public等限定符。也可以自定义get和set访问器，以便在需要的时候进行一些关联操作。比如在set的时候可以调用OnSet之类的事件委托。

---

委托，这个也是一个极好的特性。记得写Java的桌面应用的时候，一个类要实现MouseListener接口，然后在处理函数里判断if(被单击的是Button1){/*Do something*/}else if(被单击的事Button2){/*Do something*/}......如果窗口上的button多一些，这个函数可能要几百行，而且代码乱的不得了。但是如果是C#，可以为每个button的click事件指定不同的处理函数，代码清晰简洁。在IoC的实践中，C#的委托也比Java的传接口的实例更为有优势。

---

C#下，反射比Java更易用。而且C#里的MEF也是个不错的东西。我们团队之前用MEF开发了一个东西，每个模块完全解耦合，完全不需要知道其它模块的信息，只需要知道核心组件里的接口就可以调别的组件了。这样做到了在不影响其它模块的情况下，直接替换某组件。而核心组件正是通过MEF，以反射的方式发现组件并动态加载组件。

---

“约定优于配置”的理念之前看MSDN的WebCast，讲Asp.netMVC2的那集，里面有句话我印象特别深“约定优于配置”。里面的讲师开了个玩笑“你的项目里要是没有50个配置文件，每个配置文件没有100行，你都不好意思跟别人说你写了个Java项目”。这句话当然夸张了，不过Java里面需要配置文件的地方的确不少。就拿Struts2.0和Asp.netMVC来比较。Struts2.0里你需要些配置文件告诉服务器，哪个是Controller，哪个是View，哪个是Model。但是Asp.netMVC里就很清楚了，里面Controller文件夹里的XxxController文件就是名为Xxx的Controller，View文件夹里、Model文件夹里也是如此。视频的讲师当时说了一句“Controller文件夹里放的当然是Controller了，难道你真的要在View文件夹里创建一个文件名是XxxModel的Controller么？你有这个需求么？”---