自一个人默默走

写了些VB.NET的代码，用其来实现接口、实现类、实现控件，发现VB.NET的代码实在很不方便。

于是换用C#来实现，发现C#里面很多问题的处理比VB.NET复杂得多，语句更繁琐。

结论是C#语法繁琐，VB.NET语法恶心。

看来还是把设计提升到一个思想的角度，具体语言只是用来实现的，什么方便就用什么。

似乎VB.NET不是现在开发的主流吧(我指国内)，不过它真的很适合微软的风格——既然已经有了VB为什么还要搞出个C#呢？

VB.NET比C#还适合隐藏代码的实现细节，这符合.NET和Visual Studio组合的设计。之前有一阵子使用ASP/VBScript开发的经历后，我发现VB可以编写一些很舒服的代码——如果讨论类C的语言，我更喜欢JavaScript。没有一种类C语言的闭包能像JavaScript使用的那么舒服的。

刚刚有个神奇的发现：终于知道了为什么有很多ASP.NET开发人员使用VB语言了。

当指定一个页面的后台语言为VB时，其中插入的asp:标签并不会把相应的事件处理函数也写出来，比如一个按钮：
<asp:Button ID="Button1" runat="server" />
要让其响应Click事件，只要在代码中加入：
Protected Sub Button1_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles Button1.Click
End Sub
而C#会更改asp:标签，使之变为：
<asp:Button ID="Button1" runat="server" onclick="Button1_Click" />
并在代码中添加Button1_Click的实现。

使用VB的那种方式相似于jQuery的那种开发方式，也就是“渐进增强”，让后台处理事件的代码全部在一个地方；而后者要指定由谁来处理，比如要删除一个Button1_Click的处理，我需要动两个地方的代码。

一个想法就是：.NET希望实现的代码和界面分离的方法，其实VB更容易实现。

昨天用.NET 2.0写了个简单的网页控件，其中对远程获得的Atom文本进行分析，使用了XmlDocument的SelectNotes方法，使用了XPath的语法。

一个很简单的想法就是：处理XML的XPath语法只是一种简化的集合操作语法，如果要进行复杂的查询，还需要自己来编程实现。对数据库表的操作、对对象集合的操作，实际上使用的处理都差不多。而SQL语法可以完全应付这样的操作，再复杂的逻辑，也几乎可以用一个语句来完成。

于是乎Microsoft就引进了LINQ。

今天碰到一个很简单的需求，正好可以使用WCF来解决。

也可以使用Erlang来解决，但是我对Erlang的部署完全没有信心，一切都乱七八糟的。

中午想了些，下午出门一趟，整理了下头脑，发现中午的设计有错。WCF虽然简化了很多远程调用的问题，但是我却几乎没有远程编码的经验。编译出来的WCF是一个DLL文件，查了MSDN，可以通过5个途径进行部署。目前看来需要安装一个Visual C# Express的版本了，我需要编写Windows Service。

除了WCF之外，还有其它的解决方案吗？