随笔档案

The Architect (dedicated non-programming technical decision maker and problem solver for business):

架构师（专用非编程技术决策者，业务问题解决者）

1. Has outdated programming knowledge and experience, loss of touch with modern development approaches and practices.                                                                                                                                                                                             过时的编程知识和经验，对现代的软件开发方式和实践缺乏关注。   


2. Don’t program and don’t know much about evolving system internals, but makes key technical decisions. Often has completely irrelevant and unreal picture what is happening with the system.                                                                       不进行软件开发，对系统内部知之甚少，但却要做出关键的技术决策。对系统经常有完全无关和虚幻的映像（不太会翻译这句）。


3. Tends to complex, premature and generic solutions when the system is still in infancy and nothing is clear. Applies latest modern buzzword technologies as SOA, MDA, SaaS, Software Factories, etc. which look so beautiful in technical magazines, conferences and CV, but cause unnecessary headache for developers.                                      当系统仍处于起始阶段，都还不明晰的时候，常会做出复杂的，不成熟仅仅通用的决策。使用在技术杂志、技术大会和CV上看起来如此美妙的现代最新的口号，诸如SOA，MDA，SaaS，Software Factories等等，只是给开发人员带来不必要的头痛。


4. Plays role of the middleman introducing complexity in coordination and project responsibilities. Represents software team in interactions with business customers reducing communication value for the rest of the team and impacting idea flow.                                                                                                                                                                          以中间人的角色，引入复杂的协调和项目的责任。代表开发组与客户进行交流，屏蔽了其他成员的发言权和开发思想上的交流。（翻译时候意思懂了，但就是表达不出来）


5. Reduces quality of decisions, which become limited to one perspective; decision making starts lacking diversity, independence and decentralization, which are essential attributes of collective intelligence.                                          决定仅仅局限在某个角度 ，降低了决策的质量；最初的决定缺乏多样性，独立性和向下兼容，这些都是集体决策的本质。                      


6. Creates tension with developers who experience mismatch between grand design and reality. Often continues pushing design decisions until the system becomes overly complex, difficult to change and becomes completely unusable.                                                                                                                                                                                             在缺乏大型设计和实现经验的开发者之间制造紧张氛围。不断的做出决定，系统变得过度复杂，难于改变，和应用。


7. Secures job and justifies high salary - becomes authoritative center for solving business problems without much input from the team.                                                                                                                                                                            有稳定的工作和高薪，成为解决业务问题的权威，但却从未融入到团队当中。


8. Causes loss of sense of ownership, motivation and accountability in developers by detaching them from the key architecture decisions.                                                                                                                                                                     把开发人员排除在关键架构决策之外，让他们缺乏主动性和责任感。


9. Concentrates project knowledge and the big picture in one head, limiting (and sometimes preventing) complete understanding for others.                                                                                                                                                                 只精通工程知识和大局一面，对其他方面几乎一无所知。


10. Contributes to creation of specialized IT verticals that hurt relations with the business.                                                     擅长在纵向专门的IT方面建立联系，但同时却切断了业务上的关联。

            完成该系统后，所完成的后期维护工作中，最大的以部分就是数据统计查询分析功能的完善了。

       系统软件框架提供了一套报表生成系统来完成数据统计查询的功能。这条报表生成系统可以生成excel和pdf两种格式的统计报表。

       这个系统使用报表的流程大致为：

       1.每个功能都提供一系列的报表，在软件中这些报表以二维字符串数组的数据格式保存，每个字符串数组对象包括该报表的唯一键值，报表名称，报表条件提供页面以及生成该报表的具体的Java类。

       2.选择需要生成的报表，系统将该报表的唯一键值传入统一的报表控制类，首先是跳转到生成该报表的条件页面，按照功能划分报表的主要原因就是每个功能的报表条件一致，可以使用统一的控制类。

       3.提交条件后，统一的报表控制类会调用该报表的生成类,这些类需要继承统一的接口,提供了一个统一的方法，返回数据类型为Vector集合的对象，这个Vector对象容器数据对象要求为：

     两个Vector对象，一个为表头Vector，一个为表体Vector，这两个Vector对象中存储的数据为字符串数组对象。

   在具体应用中，只要将数据填充到字符串数组中，再依次放入Vector中，报表框架会生成报表。

   这个框架的一个确定就是只能接受字符串数组对象，如果生成excel格式的报表，无法根据生成的报表进行计算，必须手动的将数据调整为数字型。

大家喝的是啤酒，这时你入座了，给自己倒了杯可乐，这叫低配置；给自己倒了杯啤酒，这叫标准配置；给自己倒了杯茶水，这茶的颜色还跟啤酒一样，这叫木马；给自己倒了杯可乐，还滴了几滴醋，不仅颜色跟啤酒一样，不冒热气还有泡泡，这叫超级木马；你同事给你到了杯白酒，这叫推荐配置。

       人到齐了，酒席开始了。你现一个人喝了一小口，这叫单元测试；你跟旁边的人说哥们咱们随意，这叫交叉测试；但是他说不行，这杯要干了，这叫压力测试；于是你说那就大家一起来吧，这叫内部测试；这时候boss向全场举杯，这叫公开测试。

      菜过三巡，你就不跟他们客气了，你向对面的人敬酒，这叫p2p；他回敬你，你又再敬他，这叫TCP；你向一桌人挨个敬酒，这叫令牌环；你说只要是兄弟就干了这杯，这叫广播。

   有一个人过来向这卓敬酒，你说不行，你先过了我这关，这叫防火墙。你的小弟们过来敬你酒，这叫一对多。

   酒过三巡后，你也该活动活动了，你一桌一桌的走，这叫轮询；你突然看见某一桌的漂亮mm，走了过去，这叫优先级；你去了坐下来就不打算走了，这叫死循环；你的老大举杯邀你过去，你只好走过去，这叫激活事件。

  你向一桌敬酒，他们说：“不行，不行，我们都喝白的。”于是你也喝白的。这叫本地化；你向boss敬酒，可是boss被围起来，你只能站在外围，这叫排队；你终于到了内围，小心翼翼的向前一步，这叫访问临界区；你拍照boss的肩膀说哥们咱们再喝已被，这叫越界。

                    一个程序员对自己的未来很迷茫，于是去问上帝：“万能的上帝啊，请你告诉我，我的未来会怎样？”

            上帝说：“我的孩子，你去问Lippman，他现在领导的程序员的队伍可能是地球上最大的。”

           于是他去问Lippman，Lippman说：“程序员的未来就是驾驭程序员。”

          这个程序员对这个未来不满意，于是他又去问上帝：“万能的上帝呀，请你告诉我，我的未来会怎样？”

         上帝说：我的孩子，你去问Gates，他现在所拥有的财产可能是地球上最多的。”

         于是他去问Gates，Gates说：“程序员的未来就是榨取程序员。”

        这个程序员对这个未来不满意，于是他又去问上帝：“万能的上帝啊，请你告诉我，我的未来会怎样？”

        上帝说：“我的孩子，你去问侯捷，他写的计算机书的读者可能是地球上最多的。”

        于是他去问侯捷。

        侯捷说：“程序员的未来就是诱惑程序员。”

       这个程序员对这个未来不满意，于是又去问上帝：“万能的上帝啊，请你告诉我，我的未来会怎样？”

      上帝摇摇头：“唉，我的孩子，你还是别当程序员了。”

           该系统软件框架对sql操作进行了封装，并提供了一批API帮助客户程序员更为简便的进行数据库操作。这些api包括:

1. 
   
          统一的DbConnection管理，客户程序员只需将要执行的sql语句作为参数传入，api会将结果列表以二维字符串数组的形式返回。api提供特殊的方法，例如翻页处理等都提供了相应的处理。
   
   


2. 
   
          按照功能划分dao操作类。类的编写有自身设计的一套规范。首先该功能的dao操作类设计为接口，然后按照数据库的不同特殊处理实现该接口。例如：接口为TestDAO.java，使用oracle数据库实现该接口，为OraTestDAO.java，使用sqlserver数据库实现该接口，为SqlTestDAO.java。dao操作类直接操作框架对数据库进行操作的DbConnection对象进行业务处理。
   
   


3. 
   
         所有的接口实现的dao操作类在web服务器的一个特殊目录中存在一个xml格式的配置文件。
   

   xml 代码

   
   

   
   

   
   

   
   
   1. <DAOLIST>  
   
   
   2. <DAO>  
   
   
   3. <NAME>testdaoNAME>  
   
   
   4. <CLASSNAME>com.test.dao.OraTestDAOCLASSNAME>  
   
   
   5. <DESCRIPTION>测试DESCRIPTION>  
   
   
   6. DAO>  
   
   
   7.  DAOLIST>  
   
   

   
   

   
   
   
   


4. 
   
       在web服务器的同时，会同时启动一个线程，读入该xml文件，并读入数据库配置参数文件。与hibernate这个框架相比，这个dao管理只能在web应用中使用。
   
   


5. 
   
       前几篇提到的web层使用的Ctrl控制类，在框架设计中不能直接操作dao操作类，而是存在一个中间层，包括BO类和VOListIter类，编写这两个类都需实现框架提供的接口。bo类主要包括数据库的除获取数据列表以外的所有操作，如录入，修改等，VOListIter类专门为实现数据列表翻页设计，通过该类获取翻页数据列表方法，需要首先声明一个长度为5的Integer类型的数组，DbConnection类的该方法需要这个参数，将该列表的当前页数和最大页数返回。
   
   

       这个数据库框架还提供了一些方便编写代码的操作，例如拼装sql语句，提供了一个这样的方法：MakeUp类。代码如下：

java 代码

这个makeUp方法会将sql语句拼装好，@表示数字占位，#表示字符占位。

这个系统的数据库操作管理大致就是这样了，比较简单，总的来说就是对dbconncetion 操作进行了重新封装，方便客户程序员的使用。

           维护的这个软件系统使用了一个比较复杂的系统权限管理系统，原本的设计是将用户对软件的使用权限控制到以最末级的菜单，并根据公司组织机构的设计，上级组织单位可以将自身所获得的权限继续授权到自己的下级公司。

       为了授权权限的操作简单话，不然每次都从几百个菜单选项中选择给该用户授权的菜单权限，恐怕这个权限系统管理员就要崩溃了。:-)，权限管理系统将权限分为了权限组，权限域，基本权限管理。

      权限组和权限域的区别我至今没有太分的清楚，郁闷中····在不多的使用当中（主要是设置测试用户的权限）感觉上这两种权限范围设置是评级的，没有谁是谁的上级的关系，不清楚当初为什么设置成这样，我用的主要是权限域的设置。

     给用户授权下权限，前提是已经有相应的权限域设置。

   1.权限域设置：权限域需要相应的设置编码，并选择该权限域包括的菜单权限。

   2.在设置好权限域后，就可以直接将该权限域授权到系统用户。

   权限管理使用了数据库信息管理，现在使用起来比较笨拙，不过由于最初的设置过于复杂，如果使用现在比较统一的xml文件配置，可能使用起来也不是很方便。

   每个菜单权限项都有一个自身的权限编码，该系统的菜单全部分为三级，编码规范为：一级菜单编码_二级菜单编码_三级菜单编码。这样，在授权权限的时候可以直接将一级菜单授权，用户相应的也获得该一级菜单下所有功能的使用权。

    用户登录成功后系统会将该用户的合法权限值压到一个集合中，放到sessin对象里。

   权限的控制在系统的页面和后台控制类都有实现。页面使用了上一篇提到的页面逻辑标签实现控制，在显示该页面之前，控制类使用了个系统框架提供的公共权限控制类将该用户的权限值压到页面值中。

  在调用该功能之前，控制类现会判断该用户的权限，有一个通用类，将该功能的权限和当前的用户对象作为参数传入，该类会判断在用户的权限集合中是否包括该权限，以决定是否继续执行该功能流程。

  这个系统的权限管理部分就是这么多了，下一篇讲讲这个系统的数据库管理部分。维护的这个软件系统使用了一个比较复杂的系统权限管理系统，原本的设计是将用户对软件的使用权限控制到以最末级的菜单，并根据公司组织机构的设计，上级组织单位可以将自身所获得的权限继续授权到自己的下级公司。

       为了授权权限的操作简单话，不然每次都从几百个菜单选项中选择给该用户授权的菜单权限，恐怕这个权限系统管理员就要崩溃了。:-)，权限管理系统将权限分为了权限组，权限域，基本权限管理。

      权限组和权限域的区别我至今没有太分的清楚，郁闷中····在不多的使用当中（主要是设置测试用户的权限）感觉上这两种权限范围设置是评级的，没有谁是谁的上级的关系，不清楚当初为什么设置成这样，我用的主要是权限域的设置。

     给用户授权下权限，前提是已经有相应的权限域设置。

   1.权限域设置：权限域需要相应的设置编码，并选择该权限域包括的菜单权限。

   2.在设置好权限域后，就可以直接将该权限域授权到系统用户。

   权限管理使用了数据库信息管理，现在使用起来比较笨拙，不过由于最初的设置过于复杂，如果使用现在比较统一的xml文件配置，可能使用起来也不是很方便。

   每个菜单权限项都有一个自身的权限编码，该系统的菜单全部分为三级，编码规范为：一级菜单编码_二级菜单编码_三级菜单编码。这样，在授权权限的时候可以直接将一级菜单授权，用户相应的也获得该一级菜单下所有功能的使用权。

    用户登录成功后系统会将该用户的合法权限值压到一个集合中，放到sessin对象里。

   权限的控制在系统的页面和后台控制类都有实现。页面使用了上一篇提到的页面逻辑标签实现控制，在显示该页面之前，控制类使用了个系统框架提供的公共权限控制类将该用户的权限值压到页面值中。

  在调用该功能之前，控制类现会判断该用户的权限，有一个通用类，将该功能的权限和当前的用户对象作为参数传入，该类会判断在用户的权限集合中是否包括该权限，以决定是否继续执行该功能流程。

  这个系统的权限管理部分就是这么多了，下一篇讲讲这个系统的数据库管理部分。

       这个软件架构使用的mvc架构包括使用自身一套页面逻辑，标签类型比较简单，包括逻辑判断标签、页面赋值标签和循环list对象取值标签。

     在执行完页面请求返回的页面没有规定，可以是jsp，也可以是html页面，使用上一篇提到的Common对象跳转页面，方法为：common.showPage("page")方法，因为没有该框架的这部分源代码，只能大概推测，这个方法是读入页面，并将执行页面含有的逻辑标签和赋值，一个方法可以多次使用该方法，最后的执行结果是多个页面顺次显示，比如：      

page1 =  "page1";

page2 =  "page2";



common.showPage(page1);

common.showPage(page2);

 

page1的页面代码： 

<html>

<body>

hello,this is page1!

</body>

</html>

page2的页面代码：

<html>

<body>

hello,this is page2!

</body>

</html>

最后显示的页面代码：

<html>

<body>

hello,this is page1!

</body>

</html>

<html>

<body>

hello,this is page2!

</body>

</html>

 

       页面的逻辑标签很简单：<if><else><endif>，完成简单的页面逻辑判断

在页面最终生成之前执行的代码，common的showpage方法会将标签作为java代码执行。

        页面赋值标签写法很简单：($value$)，value为要获取的参数值，使用$符号区隔，可以和逻辑标签混合使用：

   <if ($value$)==1>1<else>2<endif>

    写法有些类似现在流行的mvc开源框架。

        另一个常用的循环标签：<loop ($list$) ></loop> list为循环的集合对象。也可以同时循环多个list集合对象，但前提是多个对象的集合大小相同，不然就会出现数组溢出的错误。

        该mvc框架配合了一套js脚本库一同使用，因此像一些常用的脚本方法就和mvc框架的一些特点结合起来使用，js代码编写量减少。

        表单提交参数验证有一套统一的方法，现在应该应用的很普遍了。在表单对象标签里增加一些属性，最后提交表单是调用统一表单验证方法，该方法会读取该对象的属性，判断该对象值是否符合要求，包括判断复选框对象是否有选择对象，例如在删除列表中的多个对象使用。

       在常用的查询列表和该列表的某个具体对象时，脚本库提供了统一的方法：

1、常用的翻页方法，首页，尾页，上一页，下一页，跳转到某一页的方法，只需要使用脚本库中统一的方法，传入表单名称参数，class名称，method名称，跳转到某一页需要再传入页面参数即可，不需在编写js代码。

2. 查看某一条具体记录，方法类似于翻页方法，同样传入表单名称参数，class名称，method名称表单名称参数，class名称，method名称，和该条记录的主键值。

    今天写到这里，下一篇写写这个系统的权限系统。

             今天总结一下这个系统软件使用的系统架构。

         这个软件使用的mvc框架有点类似于struts，我是在2005年开始接触java的，在维护这个系统软件之前使用的mvc框架包括struts和webwork两种，相比较之下，与strtus更为类似，或许也是因为strus中控制类部分也是直接操作request吧。

        这个mvc框架自身的特点大致有这么几个：

        1.这个mvc框架没有使用配置文件，在webconfig文件中配置有一个总控的servlet，负责接受页面提交的请求，进行转发。

           页面提交请求方式是直接请求这个总控servlet，在提交请求到这个servlet的同时，提交两个固定的参数，分别是class和method参数，通知servlet将请求转到相应的类，并调用参数中的方法。

         2.总控servlet调用的类为普通的java类，没有特殊的要求，比如struts中要继承action父类，方法写法有严格的要求，为静态方法，不允许有返回参数，接受的参数也固定，如下：

         public static void expMethod(HttpServletRequest req,

                                        HttpServletResponse res,

                                        RequestHash reh) throws     Exception {}

          因为没有使用配置文件，方法调用结束后返回到哪个页面，在该方法中直接赋值该页面的具体路径。这样修改起来有点复杂，需要重新编译类，并且在调试的时候，如果需要找到该请求调用的页面的具体路径，必须找到这个类和方法，不如使用配置文件一目了然。

        3.获取页面上的参数，这个框架提供两种不同的选择。

           框架提供一个Common的对象，该对象封装了对request的部分操作，提供了一个RequestHash对象，该对象为一个Vector集合，页面表单提交的数据已经封装到该集合中，参数获取方式为，创建一个字符串数组，将需要获取的参数名称赋值到该数组中，Common的toData方法返回与字符串数组相对应的参数值，如下

          Common common = new Common(req,res);//req request对象，res为response对象

          String[] keys = {"param1","param2"};

          String[] values = common.toData(reh, keys);

          此时values数组中，values【0】中的值为param1表单值，相应的为param2的表单值。

         如果需要获取一个数组值，request的操作是getParamValues方法，例如表单中的复选框值，RequestHash对象提供了类似于request的这个操作。

         reh.getParameterValues("params");

         4.为显示页面赋值也使用了Common对象。

        a、 赋值简单的字符串对象：common.addString("showParam", param);

         第一个参数为页面获取该参数值使用的名称，第二个为该对象名称。

         b、一次性赋值多个字符串对象：common.addArray(keys, values);

         相对应的，keys为页面获取参数值的名称，values为参数的值。

        c、赋值一个复杂的对象，例如自定义对象或者一个List对象：

            common.addObject("voname", vo);

          用法一致。

      该框架提供一套通用的js脚本库和一些统一的赋值规则，例如登录用户对象名称，子系统名称和提示名称，因此common对象赋值也提供了一些特殊的方法，只接受参数的值，参数名称为已定义名称，因此在为页面赋值也要注意不要与系统框架已定义对象名称冲突。

      今天写到这里，下一篇写写这个mvc框架的页面逻辑，标签还有这个脚本库的内容吧。