摘要:Rockford Lhotka在ServerSide.Net上发表了一篇文章《The Fallacy of the Data Layer》（博客园的朋友已经将此文翻译成了中文）。作者在这篇文章中表达了一种观点，即数据源与其说是整个Application中的一个Layer（Tier），不如把数据源当作Application之外的一个单独的Service。作者将Application这个词定义为：“an application is hereby defined as a set of code, objects, components, services, layers or tiers that exist within a trust boundary.”就是说，一个Application的内部是紧密联系的、互相信任的一组内容。Layer可以看作Application内部的一种层次。而数据源（通常是SqlServer之类的数据库）在真实世界中，并没有将它“完全包裹”在一个Application的里面，而是可以被其他Application（或者叫其他Service）访问的。其实作者的观点并非什么“惊世骇俗”，在很多情况下，我们早已经把Data Access Layer和Data Source 分来了，Data Source作为一个单独的“服务”存在于系统之外的某个地方，而且可以作为“插配件”一样更换和替代。我的个人观点更倾向于把Data Access Layer叫做Persistent Layer，持久层。在Application内部，我们看到的只是反映客观世界的Entity，对数据库“一无所知”，在需要保存Entity时，由持久层负责将Entity持久化，至于它是如何将它持久的，对于Domain Logic来说，没有意义。About VS2005：最近VS2005的各种测试版本开始满天飞，包括Yukon的各种测试版本，越来越“混乱”了（可怜我手头的Indigo组件还点名需要PD6版本...），在11月份的VS2005 CTP之后，12月份的CTP也快要出来了。如果想等稳定的版本，期待明年2月份的Beta2 Release吧！:)再附，To Office MVPs：OTEC（Office技术专家俱乐部）成员名单即将确定，请有意参加的Office MVPs发送邮件给我，并在邮件中附上相关信息（详见回复）。...[阅读全文]

摘要:这个有意思的问题出自Eric Gu的Blog。代码如下：public void TransmitResponse(ArrayList responses,                              StreamWriter streamWriter){   foreach (DataResponse response in responses)   {      NetworkResponse networkResponse = response.GetNetwork();      networkResponse.Send(streamWriter);   }   GC.Collect();      // clean up temporary objects}这段代码问题何在？原Blog Entry的众多回复非常有意思。首先，有人指出，代码没有关闭NetworkResponse对象和StreamWriter对象，应该在代码中加上“using”来保证正确调用这些对象的Dispose()方法。但是，随即有人指出，在这个方法中调用这些对象的Dispose()，是不正确的。首先，作为参数的DataResponse集合和StreamWriter对象，根本不能假定它们“应该”在这个方法内部被关闭，也许在调用这个方法之后，其他地方仍然要使用它们。而在循环中通过GetNetwork()方法得到的临时NetworkResponse对象，很难看出GetNetwork()方法是否是创建一个新的NetworkResponse对象抑或只是返回一个已有的对象（还有人指出，如果是创建一个新的对象，那个方法名称应该是CreateNetwork()，而不是GetNetwork()），所以贸然调用它的Dispose()也是不可取的。最后讨论的结果，这段代码的问题主要是：1、代码中未检测各个相关的对象是否为null，或者ArrayList中的对象是否类型正确；2、调用GC.Collect()毫无理由。原Blog Entry的众多回复所统一的意见：只有一个方法亲自创建了一个新的对象实例，才有义务调用这个实例的Dispose()。呵呵，我想到一个典型的“反例”，那就是ADO.NET中DataReader的使用，它的使用者在某些情况下，有义务调用它的Close()方法。当然，作为开发人员，可以利用各种模式来“修正”这个“反例”。比如，这篇文章所介绍的使用Delegate来将DataReader的Dispose责任回收到创建DataReader的地方。...[阅读全文]

摘要:在上期的《程序员》杂志上，记得有一篇板桥里人写的Java相关的开篇，文章里面讲到，SOA is NOT Web Services。William Zentmayer在一篇Blog《Doing SOA without Web Services? I'm skeptical.》中表达了自己的观点，那就是虽然很多人都认为SOA并不就意味着Web Services，但是离开了Web Services的SOA几乎没有“价值”可言。这篇文章后面的留言对作者的观点进行了“无情的”驳斥，留言者都认为SOA是比Web Services更为广泛的概念，在以往（甚至先于Web Services的出现）的被开发出的系统之中，就已经可以看到SOA的存在了。在作者随后的《Doing SOA without Web Services? Part II》中，他虽然为自己先前的观点进行了辩护（理由是，如果考虑SOA必须要满足异构系统间的通讯，就必须使用一种业界公认的标准协议来进行通讯，即SOAP和Web Services），但还是接受了SOA更加倾向于是一种Messaging System的观点。MSDN上有一篇很棒的文章，《Messaging Patterns in Service-Oriented Architecture, Part 1》，介绍了SOA中出现的各种Messaging Patterns。比如，Messaging System很自然被理解成传递Message的系统，那么在这个系统中如何实现用Messaging Patterns调用远程系统的一个方法呢？答案就是“Command Message Type Pattern”。另外，对于上面这个问题，九月份的MSDN Magzine上面的一篇《Simplify Distributed System Design Using the Command Pattern, MSMQ, and .NET》也是属于极力推荐的文章。...[阅读全文]

摘要:Enterprise Development Reference Architecture（EDRA），也就是以前的ShadowFax，在6月份已经发布了正式的1.0版本，现在项目正处在1.1的开发阶段（已经发布了一个1.1测试版本）。嗯，先解释一下Enterprise Development Application Framework，EDAF是这个项目提供的一个企业级开发平台和框架，开发人员可以基于EDAF来进行企业级应用的开发。EDRA则是对使用EDAF进行开发的一个参考、描述、规范...先看看EDRA的Architecture Overview图片：EDRA可以算是非常典型的SOA架构。可以看到图上被分为了两大块，Service Interface和Service Implementation，根据名字我们就能够大致猜出它们各自的作用和地位。在实际的应用中，我们通常可以将Interface和Implementation部署到不同的Tier，以获得更好的扩展性。我们根据这张图来从上往下的走一遍吧。:)首先，Client App发出一个Request给Service Interface，这个Request可以是多种协议的，WebServices、MSMQ、Remoting，每种协议都对应一个Interface Transport，Transport负责接受Request，并传递给各自对应的Adapter。Adapter对于Request可以做出一些初始化的处理，比如安全验证什么的，然后，Adapter会创建一个Context对象，将这个Request放在Context对象里面，然后将Context对象传递给Service Interface里面的Pipeline。Pipeline是一个配置性很高的组件，它根据配置文件，来载入各种Handler，包含了Request内容的Context对象就依次被这些载入了的Hander处理、传递，并最终到达一个Interface Pipeline Target，这个Pipeline Target是一个Dispatching Target，它可以根据配置，使用不同的协议将Context传递给Service Implement部分（Web Service、MSMQ、DCOM、或者Inproc直接调用）。Context首先到达的也是Service Implement部分的Dispatching Transport（类似Service Implement，也有多种Transport来接收多种协议的请求），每个Transport同样有一个Adapter，然后Adapter创建出Pipeline，将Context传进去。Context在Service Implementation的Pipeline里面做得事情和前面差不多。最终，Context到达了一个Business Action Target，这个Target负责调用“真正”的Business Action。Business Action根据包含在Context中的Request执行相应的操作，然后生成一个Response，将这个Response放进Context里面，然后将Context返回给Business Action Target。Context对象沿着来时的路线又一路返回，返回的路上也可能被经过的各个Handler进行一些处理，最后，Context返回到了创建它的Interface Transport Adapter。Adapter这时需要查看Context中是否包含了异常信息，并分辨异常信息是属于业务逻辑执行上的异常还是EDAF本身所产生的系统异常，如果是前者，将被直接返回给Client App，如果是后者，则进行一些Log或者其他操作后，返回一个包装好的安全的错误信息给Client App。在EDRA的主页上，同时还提供了一个Global Bank Reference Implementation，使用EDRA来构建的一个银行系统的示范项目。EDRA Wiki上也有不少有意思的内容。最后，如果对这样的架构和框架感兴趣，那么还可以去看看微软的另外一个项目：FABRIQ，FABRIQ是一个高性能的的、单向的、基于队列的一个Messaging Architecture实现。...[阅读全文]

摘要:TheServerSide.Net上有一篇不错的文章，“10 Ways to Make Your Code More Testable”（10种让你的代码更具可测性的方法），这10种方法中，有几项不但是让代码更具可测性的方法，也是写代码时必需遵循的基本Principla，但也有几项非常有意思的： 只要可行，就让方法返回一个值。这样不但可以让代码更加容易被测试，而且也更加容易让调用者了解它的运行状态。不过作者也说了这个方法并非是“非此即彼”，而是“as much as possible”。 对于牵涉到包含了数据库的操作，这篇文章提出的解决方法就是很常见的Mock Data Access Object，即在测试时使用一个并非真正去读写数据库的假数据存取对象，来模拟真正的DAO的行为。 说到牵涉到数据存取的测试，在单元测试领域这的确是一个容易让人挠头的问题。在这里我郑重推荐MbUnit这个工具，它内置了两种最常见的解决这个问题的方法，使我们的日子更轻松了。 1、RollBackAttribute，这个特性利用COM+的Transaction，将整个测试方法的操作置于一个事务里面，来达到自动回滚的目的。 [Test][RollBack]public void TestMethod()Roy Osherove有一篇文章比较详细的对这种方法进行了描述。 2、完整恢复数据库，这个方法基于一种很简单的数据恢复方式：在某个地方（通常是测试开始前或结束后），让数据库根据我们提供的Backup文件自动恢复。 [TestFixture][SqlRestoreInfo("connectionstring","databasename",@"c:\db.bak")]public class TestClass{     [Test]    [RestoreDatabaseFirst]    public void TestMethod() “SqlRestoreInfo”特性提供了必要的连接字符串、数据库名，和数据库备份文件信息，“RestoreDatabaseFirst”特性指明了在执行测试方法前先用备份文件来恢复数据库。最后，介绍一个系列文章，Automating Unit Testing With a Base Class Posts，讲解了一个进行“自动化”测试的方法。...[阅读全文]

摘要:我以前一篇文章介绍过XC#，用XC#可以非常方便的在一个Method上插入前置和后置条件的检查。XC#的实现是通过在编译时根据插入的指定Attribute动态在原有代码上加入相应的代码。Lostinet的ContextBoundModel（以下简称CBM）是一个AOP.NET的框架，在CBM的基础上，可以非常方便的实现类似XC#的前置和后置条件检查，而且具有更大的灵活性，因为我们可以自己定制各种检查的条件。下面示范在一个Person类的SetAge()方法和GetAge()方法上应用前置和后置条件：public class Person : AspectObject{...public void SetAge([AgeArg] Int32 age){    _iAge = age;} [AgeResult]public Int32 GetAge(){    return _iAge;}上面SetAge()方法需要检查传入的参数age是否如何年龄所需的要求（比如大于16岁，小于150岁），而GetAge()方法则需要检查返回的值是否如何要求。加在参数和方法上的两个Attribute，AgeArg和AgeResult都是实现了Lostinet.ContextBoundModel.IMessageHandlerAttribute接口的Attribute，所以可以用于标示拦截。下面演示了AgeResultAttribute的实现：[AttributeUsage(AttributeTargets.Method)]public class AgeResultAttribute : Attribute, IMessageHandler, IMessageHandlerAttribute{...public IMethodReturnMessage ProcessMessage(IMethodCallMessage mcm, AspectObjectProxy proxy, MessageHandlerQueue queue){    IMethodReturnMessage result = queue.InvokeNext(mcm, proxy);    if (Convert.ToInt32(result.ReturnValue) < 0)    {        throw new ApplicationException("返回值不能是" + result.ReturnValue.ToString());    }    return result;}}在ProcessMessage()方法中，代码首先调用了“真实”的方法代码，然后对返回值进行检测。如果感兴趣，点击这里下载这个示范项目的源码。在这里下载ContextBoundModel的最新的版本。[本文中所有对ContextBoundModel的资料的引用，都得到了Lostinet的允许]...[阅读全文]

摘要:1、不少人向我抱怨能够找到的实用的WebPart太少了，Microsoft在它的网站上其实提供了不少WebPart、Template、Tools等好东东的下载。当然，自己DIY，丰衣足食。2、Microsoft Solution for Internet Business 2.5版发布了，MSIB里面描述了如何高质量的用Windows Server System来构建Internet站点。网管必看！3、想知道如何设计和使用一套Framework吗？看看这里。这篇文档对Framework的一些通用原则、IoC、Spring做了简洁明了的描述，绝对推荐！（感谢文章作者，和jjx在.Net评测网上的推荐）4、Improving .NET Application Performance and Scalability正式在MSDN上登陆了！它包含了如何在设计、编码、数据库设计、测试等各个阶段对系统的性能进行调整和优化的各种原则和指南。...[阅读全文]

摘要:ShadowFax项目正式更名为The Service Development Application Framework，并发布了Beta 1.0版本，随之发布的还有一个基于它的Services Reference Implementation : Global Bank，和相应的文档资料。ShadowFax WorkPlace Home : http://www.gotdotnet.com/Community/Workspaces/Workspace.aspx?id=9c29a963-594e-4e7a-9c45-576198df8058ps1: Improving .NET Application Performance and Scalability已有pdf版本下载。：）ps2: 又一个重头戏Integration Patterns。...[阅读全文]

摘要:正在美国如火如荼的进行的TechEd2004上，伴随着新发布的VS2005 CTP?May2004版本，众人瞩目的焦点已经从ObjectSpace、Generic、ASP.NET 2.0、WhiteHorse等等New Features转到了VS2005 Team System。对于一个完整的开发平台而言，“开发生命周期管理”已经越来越被开发人员和软件公司所重视。Borland公司很早就突出自己可以在Define、Design、Develop、Test、Deploy、Manage等各个软件开发的过程提供一个完整的解决方案和工具集。VS2005 Team System就是一个可以帮助软件开发团队降低开发面向服务的应用系统复杂性的开发生命周期平台，它提供了一系列的工具，将开发团队的成员紧密联系在一起，让开发过程更顺利，开发质量更稳定。VS2005 Team System集成了Process Guidance、Prescriptive Architectures和Life-Cycle工具。它包含架构师版、开发人员版、测试人员版、团队协作版，分别着眼于对应的领域，解决对应的问题。在TechEd2004上，与会者将会得到一个Team System的早期预览版（而且能装不能卸，就是说，除非重装你的系统...），今年夏天将发布的VS2005 Beta将包含Team System的一部分，正式版将在明年上半年随VS2005一同发布。迅速了解VS2005 Team System的方法莫过于看看众多的视频Demo了：Unit and Load Testing DemosSource Code Control and Item Tracking Demo Static Code Analysis Demos ?Project Management Tools Demo 当然还有VS2005 Team System的官方站点。...[阅读全文]

摘要:最新的消息是，如同MBF一般，ObjectSpaces将与Longhorn最新的存储框架WinFS融合在一起，就是说，它已经从VS2005的计划中被移除了，并推迟到2006(or 2007)与Longhorn(Oracs)同时推出。这个消息被发布在http://msdn.microsoft.com/data，并已经在ObjectSpaces的新闻组上被证实了。相信很快会在MS相关员工的Blog上被证实。...[阅读全文]

摘要:这两天在CSDN的文档区翻到了一篇翻译的文章，《在ASP.NET中实现Model-View-Controller模式》，这篇文章是摘自鼎鼎大名的ESP，我想.NET程序员很少没有看过这本书的，说它是.NET程序员的Must-Read毫不为过（另一篇Must-Read是AppArc，即Application Architecture for .NET: Designing Applications and Services）。回到这篇文章上来，原文在这里，Implementing Model-View-Controller in ASP.NET。我当初在看这部分的时候就相当疑惑，这里所描述的实现能否准确的称为MVC？先看看大家熟悉得不能再熟悉的MVC的图示：再看看ESP中对MVC模式的描述（如果感兴趣，可以看看最“正宗”的SmallTalk中MVC模式的描述，点这里）：It is important to note that both the view and the controller depend on the model. However, the model depends on neither the view nor the controller. This is one the key benefits of the separation. This separation allows the model to be built and tested independent of the visual presentation. The separation between view and controller is secondary in many rich-client applications, and, in fact, many user interface frameworks implement the roles as one object. In Web applications, on the other hand, the separation between view (the browser) and......[阅读全文]