发布于

博客堂紧急通知

由于博客堂所在主机的机房进行迁移，博客堂将于明天下午13:00开始无法正常访问。本次迁移大约需要一天左右的时间。

另外，明天中午12:55，开心将会坐美联航班机飞往西雅图，可能于下月中旬左右回来。在此期间，开心将无法及时查看邮件，请大家见谅。

另外，博客堂、博客园以及CSDN目前正在全国范围内成立.NET俱乐部，微软将会为这些俱乐部的活动提供赞助，如果大家感兴趣，可以联系博客园的站长dudu(http://www.cnblogs.com/dudu)在自己所在的城市设立俱乐部，也可以参加本地已经建立的俱乐部。更多信息，请查看博客园的相关介绍。

发布于

李开复离开微软，加入Google

据Google消息，李开复已经离开了微软，开始担任Google China的总裁以及Google全球副总裁。

开复先生一直致力于中国的教育行业，曾经连续为中国大学生发表了四封公开信。开心在2003年也曾经亲耳聆听过他的讲座，真心希望他能够一路走好！

消息来源于：http://www.google.com/intl/en/press/pressrel/rd_china.html

开复学生网：http://www.kaifulee.com/

李开复的博客专栏：http://www.blogchina.com/new/member/_%C0%EE%BF%AA%B8%B4

发布于

Programming Indigo

Indigo开发团队的程例，应用和可用性方面的项目主管David Pallmann的《Programming “Indigo”: Code Name for the Unified Framework for Building Service-Oriented Applications on the Microsoft Windows Platform Beta Edition》一书已经出版了，该书的第三章“编程模型”和第五章“合同”已经出现在MSDN上

另外，Scott Seely，Yaniv Pessach 和Brian Nantz也在写一本Indigo方面的书，他们有个专门的网站/blog 《That Indigo Book》，上面贴有该书的一些章节以及不少跟Indigo有关的资源

发布于

the future of software

最近，Bill Gates在新加坡认为软件是技术世界里变化最快的元素，并对软件的未来做了预测，认为web services将给软件开发带来“催化剂”般的效应(catalytic effect)，而语音识别将在3-4年内成为潮流(go mainstream)。

Grady Booch不以为然，认为语音识别还有很长一段路(thanks, mvm,)要走。他还观察到，工业的某些sector，象游戏，机器人技术，移动设备，车内电子设备，军事系统充满活力，而另外一些sector，象许多企业系统(enterprise systems)，则停滞不前，另外的一些sector，象操作系统，个人效率工具，开发者工具则趋于廉价化(commoditization )。从SAP和salesforce.com最近推出的软件来看，他认为，IT业界的战争前沿，不是在Windows与Linux间，也不是在Java 与.NET间，更不是在Eclipse 与Visual Studio间，而是在特有领域的应用平台或框架上(domain-specific application platforms or frameworks )，虽然Booch先生对特有领域语言(domain-specific languages )是持怀疑(skeptical)态度的，。

发布于

"how do I see my data?"

上次提到的Scott Hanselman的帖子还是去年的，最近好象DataSet与Custom Entity之争又有升温的迹象，连我们敬爱的Dino Esposito也出手了。

在刚出版的八月份的MSDN杂志上，在他的《Cutting Edge》专栏里发表了题为《DataSets vs Collections》的文章。文章对DataSet，强类型DataSet以及Custom Entity做了详细的比较。他的结论是，DataSet和Custom Entity各有所长，两者都能达到目的，但DataSet适于做prototyping以及规模小，资金缺，周期短的项目，而Custom Entity因其带来的复杂性，大概不太适于类似项目。但对规模大，时间长，复杂的企业项目来说，Custom Entity及其集合带来的复杂性跟他们在性能，表达性，可读性以及可维护性方面的好处相比，是微不足道的。

在网上查询的时候，发现了下面这篇Frans Bouma的文章
Solving the Data Access problem: to O/R map or not To O/R map

文章内容是讨论O/R映射的，但其中的观点对DataSet与Custom Entity之争好象有点启发性。作者总结了当前对数据的最流行的三种看法，以及相对应的三种不同的解决方案：

1。数据表的方法 — 完全从数据库的角度出发，开发人员直接在内存里操作数据，解决方案无非是操作DataSet/DataTable，用存储过程或用 VS.NET生成的SQL 语句来操作数据库，用些象“数据行”，“客户记录(Customer record)”这样的术语。这是个非常流行的开发方法，其流行的原因不外于，一是有VS.NET的支持，二是与.NET之前的ADO的做法很相近。

2。Chen / Yourdon的实体(Entity)方法 — 也是从数据库的角度出发，但与第一种方法的不同之处是，开发人员是想在编码里使用关系模型的思路，对纯粹的DataSet/DataTable不感冒，爱谈论“客户实体(Customer Entity )”，而不是“客户记录(Customer record)”。这样的“客户实体”并不包含行为/规则(behavior/rules )，或者最多包含些约束(constraint)类的底层规则。对他们来说，数据库里的数据只是数据而已，而实体则是基于属性(attribute)的关系(relation)而已。这样的实体可以通过SELECT语句动态产生，这对实现报表功能很重要。这种方法一般对实体数据采用O/R映射方法，对动态数据则采用类似Dataset / DataTable的方法。这种方法也很流行，是70年代以来行之有效的技术。

3。Fowler / Evans的领域模型(Domain Model)方法 — 领域模型谈论的是业务领域里的实体，譬如象“客户”，“订单”一类的概念，包含数据和行为，所有的业务规则都在具体类里实现，通过继承和多态，形成类阶层体系，最后数据通过使用O/R Mapper保存到数据库。

与第二种方法不同的是， 领域模型里，类模型占主导地位，关系模型居于次要地位。而且在第一/二种方法里，行为一般是通过一个类似CustomerManager这样的类来施加到本身没有行为的实体上去的，而不象在第三种方法里，行为一般包含在类里，不需要类似的manager类。

至于那种方法最好，作者认为，这取决于你认为哪种方法最合乎逻辑以及你想怎么跟数据打交道，哪种方法更符合你的思路(fits your way of thinking)，是否满足类似可维护性，扩缩性，以及开发/部署的效率等等需求，这个决定往往非同小可，对软件的架构会产生深远的影响。

当然，还有一种作者没提到的方法，

4。OODB。。。。。对象即是数据，数据即是对象，不用为O/R映射烦恼，至于为什么OODB没有流行，则是另外的问题了。

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

在现实世界里，往往是以往的经历决定了采用哪种方法，试想一下，同一个.NET项目，让一个有VB背景的人做，或让一个有JAVA背景的人来做，他们的决定会一样么？