李黎敏 ——为优秀j2ee架构师而努力

初次写分层的程序，是从用户登录开始，尝试了不同的方法，首先是将许多数据库参数变量的都直接写到了数据访问层，这样对于程序修改及其不益，然后就封装到了模板层也就是实体层中，通过声明对应的常量实现，在真正的开发中有关数据访问的sql语句都是采用存储过程，然后又用存储过程的方法尝试了一下。分层有很大的好处，就不多说了，但是分层却很灵活，怎么寻找一个最优的策略，需要一个过程，这也是我们要成长的地方所在。

昨天用了多半天的时间在实现从数据访问层的DataReader返回实体类集合的功能，如果要是简单的实现不难，但是想通过融入设计模式，然后再用上自己写的SQLHelp，但是用了很长时间还是没有实现。    总结一下原因：    1、将一个循环拆开到两个函数中这种做法本身就有问题。     2、对策略模式+单例模式+接口泛化的理解不够透彻，因此程序写起来思路不是很清晰，一些vb.net的具体

在程序中的数据访问层中，经常会遇到返回实体类的情况，而不同的实体类大多具有相似的代码，情况也大致相同：有的是返回实体类的一条记录，有的是返回实体类的集合。这样如果仅按照最简单的写法的话，程序中会出现许多相似的代码，给人一种不舒服的感觉，如果发现一个程序中有许多重复类似的代码，那么就是程序中的坏味道，我们就应该想办法，对这些代码的实质进行抽象，进行优化，那么接下来要总结的接口泛型就是这么一个例子，另

分层思想的一个核心就是部件化，各个层之间是相互独立的，每一层可以随便抽取换成一个其他语言的版本，但只要与相应的接口吻合就行。我用的三层架构大致是这样的，基本的三层就不说了，然后分别为业务逻辑层和数据访问层定义一个接口，由具体的那个层来实现，问题产生了，由谁来指定程序使用哪个具体的对象来实现相应接口？为解决这个问题，我应用的是抽象工厂模式。分别为业务逻辑层和数据访问层添加一个抽象工厂。具体架

虽然机房收费系统的代码已经写完了，但是对于.net平台的一些机制的认识还是模模糊糊，记得在学习设计模式的时候就遇到了“虚方法”这个概念，但是对于“虚方法”的认识却好似一团迷雾，今天下午花了一个多小时的时间来研究这个小东东，现在总结一下对“虚方法”的认识，如有不合理之处，望各位大牛们多多斧正。     对于虚方法的官方解释比较复杂，这里就用我的理解来个通俗的解释。虚方法是相对于非虚的方法而言

这是今天下午忙活半天的成果，但不管怎样吧还是达到了想要的目的：通过集合数据自动添加SqlParameter参数到Command命令中。思路很明确，也很简单，大致的可以分两步。第一步，将用户输入的存储过程参数写入到一个SqlParameter集合数组中；第二步，将SqlParameter集合数组中的参数元素导入到Command命令的Parameters集合中。接下来要做的是分别实现这