Daniel's blog

VisualStudio引进的ASMX的确大大简化了XML Web Services的开发过程，但也存在一个比较突出的弊端，那便是VisualStudio的设计使用的是Code-first approach，先编写代码，再由.NET Framework动态生成Web Services的WSDL，而不是实施SOA更加认同的Contract-first approach。近日实践了一把在开发ASMX Web Services时运用Contract-first approach，然后通过bea Weblogic Workshop来comsume。

Step 1：生成XSD，即Web Method传入和传出XML的Schema，比如我有个叫Test1()的Web Method， 那分别为它定义Test1Request和Test1Response，如下是一个例子：

Step 2：生成此XSD对应的.NET类，命令为：xsd.exe /classes filename.xsd，有了这个类文件就可以在Web Method中方便地使用符合Schema的XML数据了（而不是手工去分析传入的XML数据）。

Step 3：生成WSDL，我用了能集成进VisualStudio的WSCF工具来完成这个工作，其间设定了Web Method及其参数和返回值使用的Schema，以下是一个例子：

注意：最后的service标签，工具不会自动生成，需要手工加入。

Step 4：生成.NET代码，这一步我也使用WSCF来完成，生成的是一个Interface和一个ASMX，此ASMX已经可以通过浏览器查看，只不过还未实现其中的业务逻辑。

Step 5：编写ASMX的业务逻辑代码，使Web Service能够真正运作。
注意：每次使用WSCF都会重新生成接口和ASMX，所以如果WSDL发生变化而需要更新，须注意不要覆盖了原先的代码。

Step 6：在Weblogic Workshop中新建一个Application，在Schema中import Step 1中生成的XSD文件，此时Weblogic会编译此文件并生成相应的XML Bean。

Step 7：在默认的Project中新建一个Java Control，选择Web Service，设定WSDL为Step 2中生成的文件，完成后便可通过这个控件开始使用此Web Service。
注意：Weblogic提供了完备的测试机制，可以自动生成测试文件，并可在测试过程中通过XML来传入Web Method的参数，这点比VisualStudio方便很多。

总结：目前此种开发方式虽然达到了很高的互操作能力，但由于集成开发环境的缺憾，生产效率会被大大降低，所以是否采用Contract-first approach还是的根据业务的需求来确定。

前些日子也是从这里得到邀请的，不知道还有没有朋友想要，发完为止吧。
daniel_ngn@hotmail.com

若是一个page1.aspx向page2.aspx提交的流程，则在page2.aspx的顶部添加如下声明：
<%@ PreviousPageType VirtualPath="~/page1.aspx" %>

设置page1.aspx的PostbackUrl属性为~/page2.aspx。

假设page1.aspx的codebehind中有名为test()的方法，则在page2.aspx中可以这样调用：
  if (PreviousPage != null && PreviousPage.IsCrossPagePostBack)
  {
   return ((page1)PreviousPage).test();
  }


顺便记录一下注册客户端脚本的方法：
static readonly string script = "<script language=\"javascript\">\n" +
"alert (\"Sorry, but we couldn't validate your credit card\");\n" + "</script>";

ClientScript.RegisterStartupScript(script.GetType(), "Error", script);

和以前的用法有点不同，所以记录下来了。

ArrayList list = new ArrayList();
foreach (GridViewRow row in GridView1.Rows)
{
 CheckBox box = (CheckBox)row.Cells[3].Controls[1];
 if (box.Checked)
  list.Add(row.Cells[0].Text);
}
return list;

Dim list As ArrayList = New ArrayList()
For Each row As GridViewRow In GridView1.Rows
    Dim box As CheckBox = CType(row.Cells(3).Controls(1), CheckBox)
    If (box.Checked) Then
        list.Add(row.Cells(0).Text)
    End If
Next
Return list

用户故事是从用户的角度对系统功能的描述，通过与用户一起探讨而得出，事实上XP的实践应由用户亲手撰写用户故事，但对很多用户来说并不容易，所以很多的实践过程中是开发人员和用户一起撰写。

开发人员依照用户故事中的描述估测完成每个任务需要的时间，并从项目经理处认领自己负责的任务，通常鼓励开发人员每次认领不同类型的任务，以提升对整个项目的认识及对不同类型技术的掌握。此处估测的时间在项目初期可能和实际完成时间有较大差距，但通过一段时间的实施之后，故测的时间也能八九不离十了。

领得自己负责的任务后，开发人员寻找结队伙伴，并开始实施过程。两者在边讨论边设计的过程中产生软件设计，并付诸测试和代码，此处产生的成果只有单元测试和代码而已，至于设计可以全部置于草稿纸上，一旦测试和代码完成便没有任何意义。若讨论过程中有明显的分歧，应该以任务负责人的想法为先。应该注意的是，这里为每个任务都分配了“负责人”，但XP的思想是整个开发团队对代码负责，而不是个人，因为事实上即使是单个任务也是由多个开发人员共同完成的。XP鼓励要经常更换结队伙伴，即使只是在一个任务中。

以下是一个用户故事的样例：

故事2运行处理退款请求故事（优先级：高  技术风险：低）
估算：开发时间 2周
2.1 获得某时间段银行的退款明细          0.5天
2.2 分页显示某时间段银行的退款明细列表，提供选择退款记录    2.5天
2.3 运行处理退款              2天
2.4 （约束）2.3可以补充退款信息卡号、姓名信息，如果要求输入卡号要输入2遍复核
2.5 （约束）2.4输入卡号提供3个4位输入第4个不限位数的分割输入，利于校对
2.6 （约束）2.4卡号栏目后面要留输入标注（本）（异）来区分本地卡和异地卡的空间
2.7 （约束）2.3可以选择部分或全部明细进行退款处理
2.8 （约束）2.3处理后退款明细记录状态要变更为运行已处理状态，并置运行处理日期
2.9 （约束）2.3按确认后要一个确认对话框，防止误操作
2.10 可以按条件获得退款明细列表          1天
2.11 （约束）2.10条件可以为：银行&退款处理状态&退款请求日期段
2.12 （约束）2.10条件可以为：商户&退款处理状态&退款请求日期段
2.13 （约束）不需要查询还在申请状态的退款
2.14 分页显示按条件获得运行已处理的退款明细列表      1.5天
2.15 （约束）2.14表头里须含查询条件信息及总笔数与金额信息
2.16 可以下载退款明细列表           2.5天
2.17 （约束）2.16数据组织成execl表格格式
2.18 （约束）2.16表可以按每个支付网关生成一份
2.19 （约束）2.16表可以按每个商户生成一份
2.20 （约束）2.16表中，部分支付网关除基本栏目外，一些栏目可以配置打印与否。
2.21 可以把运行已经处理过的退款交易回退给运行部门重新处理。
2.22 （约束）2.21可回退的退款交易必需是还没有被财务退过款的。

用HTML语法来编写xls文件尤其简单快捷，同时也具有基本的字体设置、单元格合并等功能，对于样式不是非常复杂的报表倒是不错的途径。
比如下列文本：
<table><tr><td>Data</td></tr></table>
在Excel中就能正常渲染，感觉比使用COM组件更方便点，对于普通的报表就无须COM或者VSTO来杀鸡用牛刀了。
还有点要注意的，我不知道这样写出来的报表怎样指定其单元格的数据类型，也就是说如果有一长串数字要作为字符串显示，推荐在数字前面或末尾加上&nbsp;，若是要将一连串数字以带小数的形式显示（即保留数字末尾的.00，Excel会默认去除小数末尾的0），单纯给它加上&nbsp;，会导致此单元格在Excel中无法参与运算，可以将数值格式化成带千位分隔符的形式：102,222.00，这样不仅可以保留末尾的0，也能在Excel中运算了。

最近稍微尝试了一下Microsoft Enterprise Library，感觉淋漓畅快，所以从新手的角度描述一下这个好玩的东西。

Microsoft Enterprise Library来源于MSDN patterns & practices，现在的版本是June 2005。它由一系列的.net项目和辅助工具构成，这些项目生成的DLL便是Enterprise Library的核心。这些类库是微软patterns & practices开发团队通过长期的项目实践、内部经验和大量客户反馈总结出的一系列设计模式的合集，目的是帮助开发人员方便地在项目中运用被业界广泛认可的最佳实践。

Enterprise Library是由许多Application Block组成的，每个Application Block都能实现一个特定领域的功能，比如数据库访问、日志记录、缓存管理、配置管理、加密、用户认证和授权、异常捕捉，它们既可以单独使用，也能够互相协作。由于微软提供了类库的全部源码，所以Enterprise Library具备很高的扩展性和灵活性。

使用Enterprise Library的典型步骤是：
1、为项目添加对所需使用的Application Block的引用（一个或多个DLL文件）。
2、通过Enterprise Library Configuration这个内置的辅助工具（我最喜欢的部分）对需要使用的Application Block进行配置。开发人员在可视化的环境下完成配置，工具会自动撰写应用程序的配置文件App.config和各个Application Block的配置文件（一些.config文件）。
3、在代码中调用这些Application Block以实现特定领域的功能。
4、配置项目的编译后动作，将所有的.config文件复制到应用程序可执行文件所在的目录。

推荐大家尝试一下Microsoft Enterprise Library的Hands on lab，会发现其实这套东西很容易上手，能为项目开发提供不少新的思路，免除很多原先要靠自己实现的机制，而且整个架构的灵活性、可靠性、可扩展性都会得到提高。