摘要:上次提到的Christian Nagel著的《Enterprise Services with the .NET Framework:Developing Distributed Business Solutions with .NET Enterprise Services》一书，新当选的MVP速马正在翻译，我会帮着做些校对工作。中文版的第七章可以在速马的网站上下载。...[阅读全文]

摘要: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有关的资源...[阅读全文]

摘要:最近，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)态度的，。...[阅读全文]

摘要:上次提到的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背景的人来做，他们的决定会一样么？...[阅读全文]