2007年4月18日
今天Java明天.NET，这样生活是不是混乱？
一年多的.NET生活，看来今年又要进入JavaEE的世界，郁闷。
RoR看起来不错，用起来也不错，可是一旦使用了Grails，才发现这才是真正的Java的Agile Development。
同期的两个项目，一个C/S一个B/S，一个WinForm，一个准备Grails，混乱的世界中怎样才能生存。
2006年4月30日
最近接到一个任务，需要完成在线考试系统。
问题描述：
1、学科专家将试题输入到题库系统。目前只需要支持判断、选择（含多项选择和单项选择，注意：可供选择项数不固定）
2、报名管理员负责报名，同时设定考生待考科目。
3、考试管理员在特定时间激活考试科目，准备考试。
4、考生输入身份证号，进行考试。（注意：考生在特定时间不一定只进行一种考试，可以答完一套考试，进行另外考试）。
5、考试环境为局域网，考试客户端启动后必须禁止考生执行其他任务，出于安全考虑，数据库与局域网在不同的特定网段。
6、考生有特殊标记，加入特殊标记的考生，可以设定不同的及格分数线（比如无标记考生60分及格，有标记考生40分及格）
7、考生交卷后现场得到结果，不需要成绩，只要通知考生是否及格即可。
8、可选项：最好能够进行模块化设计，根据不同的考试提供不同的抽题策略，抽题策略由考试方提供。
9、并发行：最多同时考试人数不超过120人。
10、异常性：如考试中发生问题，考试管理员可以调整考生状态，比如重新考试。
准备近期将全部开发过程记录下来，包括需求分析、系统分析、系统设计、系统实现。根据要求，初步考虑采用.NET系统开发，根据第5条要求，客户端只能采用Windows客户端，Web 客户端是无法禁止考生执行其他任务的，初步考虑可以采用 .NET 的 SmartClient 技术。根据第5条数据库要求，只能采用服务器组件与客户端交互，根据局域网环境，初步拟定采用 .NET Remoting 技术。、、
休息两天，开始进行用例设计，不过还是没想好，采用 RUP 还是 XP？
2006年1月21日
一、引言
现代的企业开发中，越来越多地引入了多层架构设计模式，即使是小型的企业信息系统也逐渐向多层架构发展，以满足系统的可伸缩性以及可维护性。目前企业开发的平台占主导地位的是 J2EE 和 .NET 两大平台，本文并不是去对比两大平台的优缺点，以免引发宗教式的争论，而是在两大平台的基础上探讨如何进行数据库的设计，将设计模式引入到数据库设计中，以期达到良好的、可管理、可伸缩的数据库设计。
传统的数据库设计理论，更加关注的是数据库设计范式，这是数据库设计必须要遵守的规则：
第一范式（1NF）：在关系模式R中的每一个具体关系r中，如果每个属性值都是不可再分的最小数据单位，则称R是属于第一范式的关系。
第二范式（2NF）：如果关系模式R（U，F）中的所有非主属性都完全依赖于任意一个候选关键字，则称 R是属于第二范式的。
第三范式（3NF）：如果关系模式R（U，F）中的所有非主属性对任何候选关键字都不存在传递信赖，则称 R是属于第三范式的。
一般认为设计数据库时能够达到第三范式即可，这也是大部分数据库原理课程所要求的数据库设计结果。但现代关系数据库管理系统中，除了支持数据库中的数据查询、更改、插入和删除外，更有强大的企业级功能支持，像存储过程、触发器和分布式查询处理，无疑，我们的数据库设计如果只满足几个范式的话，充其量只是完成了数据的存取要求，而无法和企业程序良好的结合。在设计企业应用中，数据库是企业应用中最重要的一层，是企业应用的信息起点和终点。如何将业务逻辑在数据库系统设计中正确、良好的表达，不仅涉及到系统实现的不同方式，也涉及到企业应用的成功与否。
本文试图探讨在数据库设计中如何应用设计模式理论，形成一种数据库设计模式，以避免业务逻辑层对数据库层的信息耦合，达到业务逻辑在不同层之间的正确转移与实施。
二、分布式多层应用中数据库设计的疑问
现代的企业应用程序大多采用分布式多层应用模式。如下图所示：
从上面的示意图中可以看出，无论是微软的 .NET 平台还是 J2EE 平台都表现出将业务逻辑单独放置在业务逻辑层中的意图，也即 .NET 平台中的 Web Service，J2EE 平台中的 Enterprise Java Bean。
J2EE 平台发展较早，并且理论非常成熟，很多技术和架构都在 J2EE 中产生，然后才有相应的 .NET 移植与实现。在 J2EE 体系架构中，核心的是 Enterprise Java Bean 技术，而 Session Bean 更是成功的设计。在 J2EE 中，利用 Entity Bean进行了 O/R 映射的尝试，但因为 Entity Bean 的设计复杂以及无法进行单元测试等缺点，在 J2EE 社区中颇多微词，也导致了 Hibernate、JDO 等轻量级 O/R 框架的产生。而在微软的 .NET 平台中，也出现了 NHibernate 的移植框架，微软本身也在进行 Object Spaces O/R框架的开发。
通过研究O/R 映射，让程序员和设计者产生了这样一个感觉：无论是 Entity Bean、还是 Hibernate 和 JDO，都强调 O/R 映射关系，让程序员和设计者可以用面向对象的思维方式来考察系统，而不用关心数据如何在底层存储，甚至我们只要在系统中设计好对象实体，然后利用 O/R 映射去自动实现到数据库的映射即可，程序员不需要关心数据库，不需要知道任何 SQL 的语法，只需要通过专门的 EJB-QL 或者 HQL 语言进行数据的处理即可，而无需在程序中书写任何的设计数据库存取的代码。这样编写的程序有利于移植，如果需要更改数据库系统，仅仅重新改写 EJB-QL 或者 HQL 语言既可。
虽然看起来很美，但这却是一个美丽的谎言。
首先，在企业应用设计中，当选择了一个关系数据库系统后，在实施时企业将花费大量的资金购买数据库系统使用许可，而且数据库系统的实施、安装、日常维护也需要专门的人员来完成，更换数据库系统意味着企业的巨大损失，基本上不可能出现更换数据库系统的情况。
其次，大型数据库管理系统有着良好的设计和优化功能，而且不同的数据库系统有着自身的特点，很多特性是独有的，是不可移植的。采用 O/R 映射会损失数据库系统所特有的强大的功能。
第三，无论在进行系统设计时如何优化性能，O/R 映射最终都要转化为实际的数据库连接，进行实际的数据库操作，而这些任务是无法和数据库系统内部的存储过程、触发器的性能相比较的，而且即使通过连接池，也会增加数据库连接的负荷。
所以，良好的数据库设计仍然是企业应用中非常重要的步骤。
三 在数据库设计中应用 Façade 模式
当前系统设计中有大量的设计模式，Façade 设计模式更是深入人心。Façade模式描述为：“为子系统中的一套接口提供了一个统一的接口。Façade 定义了一个更高层次的接口，使子系统更容易使用。”在系统设计中，Façade 是应用最广泛的设计模式，利用 Façade 模式的思想把构成子系统的一套业务对象“包装”在Façade 接口中。这样，Façade对象作为客户端访问业务对象的拦截器，屏蔽了业务对象。客户端访问Façade对象来代替访问底层的业务对象，当一个客户端需要调用多个业务对象的方法时，它只需要进行一次粗粒度的远程方法调用，将请求送给Façade 对象, 再由Façade 对象通过本地方法调用，调用相应的业务对象，执行其方法。这样就减轻了网络负载，提高了系统性能。并且当底层业务对象的方法改动时，只需要修改 Façade 对象，而客户端可以保持不变。这就减少了客户端和业务对象之间的耦合度，同时客户端也不必管理事务的细节。如下图所示：
由 Façade 设计模式我们可以看出，如果将数据库系统认为是一个底层的业务系统，我们应该在设计数据库系统时隐藏底层的细节，而将所有对数据库进行的增、删、改、查询操作统一到一个 Façade 接口上来，这样在系统设计的过程中，所有与数据库系统打交道的业务组件无需关心底层的数据库存储方式，而是将底层的数据按照系统实体的方式展现出来，再通过 Façade 接口进行变换，将实际的实体提交给业务组件接口或者将实体持久化到真正的数据库表当中。
比如，在设计学生选课管理系统中，底层的数据表可能包括课程表、学生表、选课表以及成绩表，但对外表现出来的实体应该只有学生和课程两个实体。然后可以通过一个存储过程暴露出来一个学生选课的功能，在业务组件中调用。同时应设计触发器，当插入选课信息到选课表的时候，在相应得成绩表中插入相应的记录。而在业务组件端，仅仅看到底层数据库系统暴露出来的一个功能，即使数据库系统的设计发生变化，也不会影响业务组件的功能。
随着 SQL Server 2005 的发布，已经可以在 SQL Server 2005 中使用 .NET CLR 来进行数据库的编程，这对数据业务逻辑的封装提供了更好的支持。Oracle 已经支持 Java，并且也在进行 .NET CLR 的集成，IBM 的DB2 也有类似的功能。
采用Façade设计模式，能够较好的隔离底层数据库系统与业务组件之间的耦合，但物极必反，过度的使用存储过程也可能带来不必要的设计麻烦。在数据库设计中，适当的暴露底层的视图也是一种良好的设计风格。一个全面的、良好的设计才是系统成功的保证。
2006年1月20日
这几天做了一个程序，VS 2005 + SQL Server Express，仔细查阅文档，发现 SQL Server Express 支持 XCOPY 部署方式，也就是说，只要目标计算机有了 SQL Server Express，那么只需要把数据库拷贝过去，可以在程序的同一个目录中，然后在连接字符串中配置 AttachDBFileName 参数即可。数据库会自动挂接到 SQL Server Express 中，运行完后自动 Deattch。感觉不错，照猫画虎，结果出现了一个错误：“数据库已被压缩，无法建立，需要解压缩”。晕死，什么时候压缩了？莫非是 Shinrk 的问题？搞了 n 个小时，无解，睡觉。
次日再战，查阅资料无解，查阅 Internet 无解，想放弃，又舍不得。无意中发现，在管理界面中 Attach 数据库居然也是这个错误，而在原先目录中的数据库居然没问题。把数据库拷贝到程序目录（在 D: 盘，SQL Server Express 安装在 C: 盘）就会出错。不会是这个问题吧？
将程序目录移动到 C 盘，居然一切正常，然后彻底晕死。难道自动挂接数据库必须在 C 盘？？？
另，如果将数据库文件设置为只读，则无论在哪个盘都可挂接，只是成为只读数据库。
虽说解决了问题，可是不懂原理，是 Bug，还是我的系统问题？
其实，Sybase 的 SQL Anywhere 真的不错，在启动数据库的时候才启动数据库管理系统，系统运行结束，数据库管理系统自动结束，如果 SQL Server Express 也支持这个功能就好了，我可不喜欢不用数据库的时候还有一个 SQL Server 服务在运行。Access 连存储过程都不支持，微软，想说爱你并不容易。
2006年1月14日
客户需求非常小，小到两个小时就可以完成，用什么实现？实在头疼。
本来想用 Office 解决方案，可是客户说不够专业，晕死。
用 .NET 反倒是方便，不过还要安装一个运行库。用 VB 或者 VC？
数据库怎么办？看来 XML 是唯一的出路。
2005年12月3日
昨天VS2005、SQL Server 2005在中国发布了，没有机会去北京，只能在新浪上看直播。从vs2005 beta2开始就期待着这个好日子，期待着中文版能上市。从昨天下午到今天早晨，我失望了，看不到中文版，整个发布会感觉非常不好，情景剧的创意不错，就是表演得太差，不过专业技术人员能表演成这样也就不错了。
唐朝的表演也一般，可能现场没什么人喜欢摇滚。我是在大学的时候喜欢唐朝的，都10多年了，不知道记得的人还有多少。
英文版11月7日发布，转眼就可以在微软网站上下载正式的 SDK 2.0了。期待着中文版的 SDK，从昨天下午到今天早晨，搜索了 N 遍微软中国网站，失望了。连中文正式版什么时候出来都不知道，莫非在中国要发布 Visual Studio 2006 中文正式版？？？
微软的 VS 发布太匆忙了，到现在 Team Server 还是 Beta3。
.NET 2.0确实不错，对于我这个从 J2EE 转过来的人来说，.NET 有好多好东西，就是等待的时间太长了，让人太失望了。话说回来，J2EE 5.0 也是难产。
难道真的是 .NET 不错，可微软已经失去了方向？？
实在太失望，放在首页请大家见谅。
2005年11月28日
前几天刚刚从上海回来，颇有心得，权且记录一下，当作日后的回忆。
当2000年在北京遇到大学同学时，当看见我那兰州铁道学院硕士毕业的同学在北京过着的悲惨生活，让我感慨万千。他说，他最大愿望就是能够在北京买一套房子，好准备结婚，然后又说，你知道吗，我都已经33了，想有个家了。我不知道怎么安慰他，我已经有了自己房子，有了可爱的儿子，我无法理解他，无法理解北京的同学说这就是一个外地来北京工作的工程师的缩影，我甚至都无法体会他如何生活在一个13平米的房子中长达3年之久，对我来说，可能一天也无法忍受。我跟他说来我单位工作吧，至少你的房子没问题，你会生活得很惬意。可他决断然拒绝了我，他说他一定会在北京生活下去。我问为什么，他说，这就是北京。这是我的第一次对北京留下的悲惨印象，尽管这只是表面上的印象。
当2002年去北京的时候，他已经在回龙观贷款买了自己的房子，正在筹办婚礼。我在地图上仔细观察了回龙观的位置，发现居然和我的城市相比已经可以算上县方那么远了，而且房价居然如此之高，超过我们市区中心的房价了，我再一次体会了北京的生活，再一次庆幸我的生活比蜜甜。这是我第二次和北京的短暂接触。
上海一直在我的心中是一个国际化的都市，是一个要去玩一玩看一看的城市。2003年当我在上海外滩闲逛时，感叹黄浦江不知道见证了多少英雄豪杰。在上海匆匆的几天，我只是留下了上海人多、车多、楼高的感觉，感觉烦躁，感觉不安，感觉这是一个永远也不会让我心动的城市。在以后的日子里，看到了徐家汇的房子已经10000元才能买到1平米，想着上海人如何生活的悲惨，对比着我已经楼上楼下电灯电话的幸福生活，我对自己说了绝不去北京上海的N个理由。
前几天，当飞机在10000米的高空飞行时，我还在想着自己说过的决不去上海北京的N个理由。飞机降落在浦东机场，我匆匆赶往上海火车站直奔杭州。这次唯一的遗憾我没有在杭州停留很长时间，只是一个上午，参加一个会议，然后匆匆赶回上海。在杭州的火车站，看到了欢迎来到休闲之都--杭州的广告，无疑对杭州平添了几分好感。人原本就需要休闲。西湖很美，但我很匆忙，没有使时间去仔细体会她的浓妆淡抹，只是在出租车上和她擦肩而过。杭州的出租车倒是档次很高，要比北京和上海高，居然都是帕萨特和现代，而且打车需要等一段时间，看来杭州的经济一定不错。虽然时间很短，可是也远远的欣赏了杭州的山和杭州的水，只是没有见到令我心动的杭州美女，不免遗憾。如果老了，在杭州生活应该也是不错的选择。
回到上海，住在上海大学，看着晚上教室闪出的灯光，不禁怀念大学的生活。多幸福的学生，什么也不用想，不用考虑做饭、工作、挣钱，只要读好书就行了，真是羡慕。于是产生了一种想再回学校读书的感觉。
第二天晚上和同学去苏武牧羊吃饭，居然要排队，让我不爽。价格倒是公道，就是人太多，等了50分钟才轮到我们，我们花钱还要排队，真是哭笑不得。这恐怕也是大城市的特点了吧。我的这个毕业于北航的博士同学，说他想回北京，上海的生活成本太高，1个月的工资不够买1平米的房子，还是北京便宜。我问他，为什么不会到他出来的小山城，他说他无法适应那里的节奏，太慢的节奏，晕死，慢还不好。细细想想，如果让我在农村生活，可能是无法适应。
转日，上海的朋友请我去新天地喝酒，原来一直以为是一个酒吧，去了才知道是好多酒吧。在那里，当喝着长岛冰茶，听着菲律宾歌手唱着英文歌，我的心也在慢慢转变。我已经无法分辨我是在国内还是在国外，身边的外国人比中国人还多，静静地听着优美的旋律，我感到了从未有过的感觉。我开始喜欢上海了。我知道，一个人如果不在一个城市呆上3年，他就绝对不会属于这个城市。他只是一个过客，一个只能在城市流浪的人，而不能和这个城市一同呼吸。但在那一瞬间，在新天地喝酒的一瞬间，我发现我喜欢了上海，喜欢了这个城市。
考察了上海几个软件公司之后，当我知道了上海的工作效率，当我知道了上海的发展前景，当我坐在返程的飞机上，我感觉我的心在动摇，我感觉到了上海带给我的留恋，不仅仅是高楼车流，忙碌的节奏，温馨的酒吧，美丽的外滩，更是一种开放，一种发展，一种活力。
我真的不去上海吗？
今天开通了博客园的博客，看来是需要记录一些感想了，想想计算机的发展，想想自己这么多年的艰辛与乐趣，看来需要慢慢的倾诉了。