泥巴麒麟的BLOG

泥巴麒麟 说:
帮我找个女朋友来，南航本科工作五年，月薪5k,173，特别帅
 
豆豆 说:
帅你MA个头

泥巴麒麟 说:
就不许我夸张阿

豆豆 说:
那也太夸张了

浪费了好几天时间，不过感觉挺有用。
就是把所有的中文自动检索出来，然后手工指定Key，最后全部替换
欢迎试用
http://www.blogjava.net/Files/black_zerg/autoI18N.rar

    晚上又听到乌龟在床下爬阿爬阿，于是就伤感起来。这两只是母亲刚买回一月余，个大，像两个会动的黑包子，然而却和我不亲近，怕生的紧
    小时候养过一只乌龟，大概是刚上初中吧。活泼。爬得很快，有我手掌大。眼睛很明亮，吃饭吃肉吃虾子。然而却没照顾好，大致是我去深圳的第三年的冬天，死掉了。回来南京后，过了几日，突然想起来乌龟，母亲于是叹气，于是说死掉了。母亲也很难过，我忙说，没啥没啥。
    算算这乌龟也跟了我十二年，结果给死了，临死我都没在家照顾着。
    今天网上查了一下，按照母亲的描述，我的乌龟可能得了白眼病。

白眼病
病因：由于饲养密度过大，没有及时进行换水，导致水质变坏，碱性过重而引起。发病季节多在春季和秋季，越冬后的春季为流行盛期。该病多见于巴西彩龟、乌龟、眼斑水龟、锦龟等，且以幼龟发病率较高。 症状：病龟眼部发炎充血，逐渐变成灰白色且逐渐肿大。眼角膜和鼻黏膜因眼部炎症而糜烂，严重时会双目失明，呼吸受阻。眼球的外部被白色的分泌物掩盖，眼睛不能睁开。病龟常用前肢擦眼部，行动迟缓，严重者停食，最后因体弱并发其它疾病而衰竭死亡。有些病龟在发病初期仅有一眼患病，如不采取措施，很快另一眼也出现症状。 
   
   然而就死掉了阿。从初中陪我到大学，会跟着我妈跑得乌龟，我就丢在家里不闻不问。终于就死掉了阿。
    噢噢，死掉了阿。总觉得欠乌龟甚多。那时候喜欢的时候就拿出来玩玩，不喜欢了就丢在角落里。它就终日在窄小的水盆里，一个龟孤孤单单过了这么多年，最后也没照顾好，就给死掉了。
  
  离我的乌龟死掉，应是三周年，以文记之。

    
  
  

         新公司还不错！
        文档和讨论都比较有意思.代码也蛮清晰,         
        代码很有些ejb的风格。我以前以为我做了那么多dao还比较麻烦，这里bo都分得很清楚，真是细致阿！ 
       下个星期就要完成一个信息库的工作.要加油。不过jbuilder用不习惯，而且机器也有点慢。现在赶着做事情，所以先用eclpise开发算了，以后再看看能不能熟悉jbuilder。心里还是喜欢eclpise多阿
     

      换到一个新地方拉。开心啊。啦啦啦。这次找工作挺顺利阿，中兴和中兴软创都通过拉，不过听说太累，最近身体也不舒服啊，万一病倒没人养家阿！只好放弃拉，心好痛啊。
      新的地方用struts和jbuilder。看了看代码觉得还比较清晰的，特别是文档作的蛮正式的，公司规定什么的也都比较人性化阿，希望以后工作顺心！
      原来公司还欠我两个月钱，希望不要赖我的阿，下个星期再催一下！
      周末啦，肚子饿饿。日子就这么一天天地过亚！噢噢
     寂寞的心情阿 如夜色般平静 

讨厌delphi,想做java阿。现在已经做到
来电显示客户
通话全程录音
可软件拨打电话
可定时任务批量拨打（类似催缴，据说用来客户关怀，放生日歌之类）
其它数据库功能，客户资料管理，附属资料
加了日程计划/万年历/邮编/区号查询等乱七八糟的功能。
程序里那边用个状态机 响应接口事件，录音效果也还不错。
越做越没意思啊，不喜欢delphi.

applet 项目方面。事情不顺利。狂补swing,

在界面模块化上面完成了基本框架设计。完成基本的模块类，做到模块和菜单可配置。
技术上完成了一个类似displaytag的控件，用了ognl,jfreereport和 jfreechart西，可以自动显示list，进行统计，打印，输出pdf,excel等, 见图。
这种通用性的控件居然没有现成的而且也没看到什么探讨，applet和swing确实不流行，这让我比较沮丧。

而且目前公司只分配我一个人在设计开发，如果只有我一个人能做的话，会非常吃力。我的担心还是比较多的，而且这两年都在作一般的bs,真正开发applet的时候，在思路上感觉很不习惯。
感觉公司方向不明确。applet似乎确实有界面上的一些亲和力，但一定是有一些问题，才会应用的这么少。

选择这个技术是有相当风险的，而且如果确实有决心把这一块做好，就应该多一些投入。客户系统现在做的人这么多，如果不是做得很优秀，怎么能够打开市场？目前没有能和我一起研究这些问题的。中途有个小单又让我去做单。真是让人失望。

webwork+spring+hibernate做的那个工单系统已经实施了几个地方，没什么问题。

最近不是很顺心，前一个月一个人到资溪做一个催费系统的项目，为了一些技术以外的事情弄得不是很顺利。回来之后，公司又让做一个来话通一样的软件，说感觉有市场，算是一个新产品。我就拿了许久不用的delphi来做，感觉兴味索然。
 delphi 的项目，大致是要做一个来电配合客户系统的小东西，我用了apro的控件，可以操纵modem，但是用modem似乎有很多问题，网络上和厂商都有评论，目前弄了几家的语音盒来搞。今天要调接口。向经理保证了这个星期弄出来，对于市场等，实在没有太多信心。拿出5年前用过的delphi，搞阿搞的，技术上实在没有什么意思。

                   关于applet
   近年来，web的html技术框架一直是j2ee应用的主流，表示层技术有：struts,webwork,spring-mvc等。

从用户角度来说，这些view层技术提供的重点功能是：

1．完成用户状态的保持 （例：一个用户的登陆状态，购物车里的物品）

2．特别的，表单信息的保存（用户输入后，如果不成功，回退页面，必须显示原信息）

3．Validation机制

4．数据显示（使用model往view中拼装数据）

5．i18n等常见问题有较成熟的解决办法

    程序员角度来说，这些技术提供了如下便利

1.流程控制有一个较为集中的配置文件。便于修改

2.mvc分离，有较为清晰的逻辑结构

3.有些框架的拦截机制等，可以集中一些通用逻辑。

但在实践中， web层的系统千篇一律，不够美观。在电信前台大量输单等应用中，实上也不够方便。web的优势是易于分发，统一管理，同时提出了很多良好的设计理念和框架模型

其实我们最早用delphi做c/s或者三层架构（加应用服务器）的时候，是多么如鱼得水，显示几个数据表，做几个master/detail，真的是手到擒来，拖拖拽拽而已。在web程序中费尽心力才能解决的难点，在application将化为无形。

但applet应用较少，关键在于：
    客户浏览器不能直接支持（很可能需要装j2se)，
    没有很好的应用框架来减轻程序员的负担，我手头的gui工具也不够理想，开发需要对swing有较深理解。applet技术近四五年来一直停顿，基本没有什么成熟组件的支持，没有现成框架，没有开源tag,没有css/javascript支持，开发效率可能不高。
目前基本框架设计如下：

 

DB :       数据库

Dao:       使用hibernate实现的瘦Dao

Service:    Spring管理的业务外观,实现事务粒度,Dao被注射

Module:    Service 将 Dao实例注射到Module,这里将完成业务逻辑。

Dispatcher  位于logic，是service的一个分发器，采用反射机制，自动调用service对应的方法

Servlet     负责和applet通信，通过Dispatcher  调用业务逻辑

Applet     view的实现

 

特别：

1．Dao的实现

在上一个项目中，我为每个实体类都作了一个Dao，但hibernate使得dao实现非常简单一致，在代码中事实上就导致了大量非常类似的贫血Dao实现。所以这次准备只做一个Dao接口，通用于各种实体类，虽然不够清晰，但结合hibernate的强大应是可行的。

2.        Servlet和applet的通信，采用ObjectStream方式，简单省力，将完成一个专用的容器类,同时注意，applet中将直接使用domain对象。

3.  最后可在server端预留webwork环境备用

关于Applet技术：

1.      所有的业务逻辑通过ServletClient访问。

2.      所有的资源(图片，声音，文件)从 Resource获得，内部采用getResource();

3.      i18n问题采用resoucbundle,通过I18N转换（这里不知道有否更好办法）

4.      外观和风格用Sun的标准，暂不另加

5.      报表技术采用freeReport，拟用反射技术实现运行期报表，其余采用simpleXml格式完成报表设计。

6.      freeReport同时解决了数据输出问题(pdf,xls等);

7.  所有相关jar需要做applet签名以获得本地操作权限

效果示例：

 

 

 

hibernate是一个伟大的工具，嗯。真是用到上瘾

数据库和类的关联设计和命名规范
常见命名:

id   物理索引，无任何逻辑意义，所有关联全部通过id

name  名称
desc  描述
cust  客户
user  用户
acct  帐户
addr  地址
posi  位置
code  编码
tele  电话
type  类型

chname 中文名称  这里并非唯一标识，需要的时候使用（name和desc不能满足的时候)
remark 备注

我们看到，实体类的设计中，我们牵涉如下类型的field:
1. id
2. 简单field ,本表就记录完整的资料
3. 对象   manytoone关联，典型的就是类型关联。
4. 对象   compement，应该抽象出类，但并非manytoone,典型的如地址(路，街，号)
5. 集合对象 manytomany，典型的如学生和老师的关系。

特别的我们看到type类型的设计，这是典型的多对一
所以在设计应该如下：
class Customer{
        CustType type
        ...
}
CustType extends Type{
        ...
}
class Type{
        String code;
        String name;
        String desc;
}
在hibernate的hbm中，我们使用manytoone。
而在整体设计中可以考虑把所有的Type做成继承结构，而用一张表来存放所有的type
例：
 code/name/desc/type
 101 ，new,新装，CustType
 102，del，拆 ，CustType
 101,new,新装 ，UserType

相对的，如果并非典型的manytoone,如地址
可以使用compement的设计

另外我们可以作一个类似数据字典的类字典设计,使用一个持久类来存放。
作用是1.待查，2.可以用于界面
class ClassDict

field      /name     /desc
Cust.Type，客户类型，表示客户的类型（如大客户，代理商等)

目前情况：

       自动工单管理系统，使用自开发的类似struts的架构，数据库访问经过包装，返回string数组。 其架构问题：

Action使用同步锁，导致在同一时间只能进行一次web访问，如同时有其他访问，将不必要的被阻塞。

结构不够清晰，不能够完全按mvc的思想明确的分离各层逻辑。jsp代码过多且结构零乱，没有把通用的代码用taglib等技术抽象，后续开发困难

业务逻辑和数据库紧密相关，而没有从表实现中抽象出来。同时，在每次使用同样的业务逻辑的时候都要反复的进行相关sql编程。故而与数据库有强耦合，相关程序重用性低，可读性差。其翻页机制逻辑横贯架构，使层次高度耦合，而数据库封装也可能存在性能问题。

同时，客户也提出了不少整改意见，而在原版本的修改和升级都会较为困难，而且对长期的维护不利。

项目分析：

       目前的各种业务管理系统还是将以j2ee的b/s架构为主流，所以有必要完成一个通用的，稳固的整体架构作为以后各种应用的坚实基础。

我认为应尽可能使用业内先进的免费框架技术而不是自开发框架。好处是：

这些框架技术凝聚很多业内精英的智慧，而且经过发布和使用，技术体系已经成熟，性能有所保障。

层次清晰，符合先进的技术理念和设计模式。同时也容易找到熟悉相关技术的人才，维护和后续开发方便。

相比之下自开发框架因为技术实力和时间问题，很难达到这些业内领先框架的技术高度。

   分析一般的j2ee应用，应有如下层次：

显示层 负责界面显示，接受用户指令

显示层有较为经典的MVC，即model,view,control，进一步了细化了显示层的工作。此类著名框架有struts，webwork,spring-mvc等。经考察，我认为struts虽然是时间最长最成熟的技术，但易用性和一些架构理念不如webwork，而view层的开发应尽可能简单快速。故选定用webwork.

 

逻辑层 负责进行业务逻辑的实现

目前的开发过程，往往陷入逻辑层和数据访问层不能分离的情况。面向对象的项目开发最后演变成成程序员在程序各处手工写sql操表。这样做的优点是开发迅速有效，问题是结构将日益混乱，每次逻辑的变化将不得不修改分散于各处的sql语句，而后续的程序员也必须了解整个程序和数据库结构才能进行修改。如果是短期小型项目，可以用这种方式。否则的话，我认为应尽可能贯彻面向对象思想，把业务逻辑抽象出来。

而逻辑层的工作就是针对实体对象进行业务逻辑的实现。我们针对所有的业务操作，对外提供service接口，既服务接口。这类似tuxedo和ejb所采用的业务外观模式。而为填补service生存周期管理的空白，我们使用著名的spring框架。优点：

实现Ioc，使各层次的耦合可配置化。

按需要实现单例模式等，进行生存周期管理

事务管理。Spring的宣言事务管理（Declarative transaction management）使得一般场景的代码中将不需要考虑事务问题而集中于业务逻辑

拦截机制将为程序提供很好的扩展空间

 

    3.  数据访问层 负责将类操作映射为数据库操作。进行实体类的持久化。从而将所有的数据访问工作集中起来

           这一层我们将完成实体类持久化(persistence)，有若干选择：

                     1 jdbc实现

                     2 使用ORM工具 如hibernate,ibatis,jdo

经过实写代码，感觉用jdbc实现dao效率非常低，而且容易出错。经过考量选用hibernate。和ibatis相比虽然上手慢且不够灵活，但其架构思想和强大功能都受到业内一致好评，甚至是ejb3也深受hibernate影响 。所以hibernate是很好的选择。

项目设计

              综上，我们使用 webwork+spring+hibernate的架构。

版本：webwork-2.1.7  spring1.2   hibernate-3.0.3

 

经过一段时间的开发，目前架构基本成形：

      

在src目录下为java源码 dao    负责数据访问对象的定义和实现  其中Dao结尾为接口，Impl结尾为实现。目前一般用hibernate做实现。 domain 实体对象 logic   针对实体对象封装的逻辑  这里service是外观接口，serviceimpl是实现，考虑目前情况简单，并没有进一步分离逻辑，业务逻辑都在impl中完成。 web    界面相关的java类  common是一些常用类，如处理中文问题的filter.  displaytag中放了displaytag相关的类，多为wrapper.  webwork中都是对应的action， 其中 BaseAction是基本的抽象类，基本后续开发应继承此类 CrudAction是为了一般的Crud工作而作的一个抽象类，可以继承用来简化工作。 而CaseDispatcher负责菜单点击后分发到相关Action，同时处理权限和session工作。   其他action按模块进行了组织

左边是webroot的结构     重要的配置文件有： Spring applicationContext.xml applicationContext-db.xml Webwork xwork.xml webwork.properties i18n  labels.properties log4j  log4j.properties displaytag  displaytag.properties dbConnect  jdbc.properties

 

关于一些技术难点和细节：

1．  各框架连接：spring到hibernate使用spring的hibernate支持。Spring到webwork使用autoware的拦截机制自动装配。

2．  列表的问题，采用displaytag。功能强大，使用简洁，可实现排序和数据导出。

3．  数据下载，使用displaytag自带的excel下载

4．  文件上传，使用webwork提供的解决方案，用拦截机制实现。

5．jsp代码组织方面，我们使用taglib和css技术使jsp中页面逻辑减少到最小，一般情况完全可以不使用<% %>的script段 。同时我们使用两个include来包含常用的taglib定义，js引用和html结构，使jsp代码非常简洁。

6．  中文问题 我们使用filter来解决页面gbk到java程序unicode的转换，同时通过正确的设置数据库连接url完成和数据库之间的交互。

7．  I18n国际化。我们要求在jsp代码中不出现中文，所有提示信息都通过资源文件labels.properties来完成。页面中可以使用jstl或webwork标签来调用。

8．  界面验证问题。使用webwork的validate机制用xml定义，或在action中代码判断。

终于决定用这种架构了，我认为相当完美了。目前为止，一切顺利阿。同时把hibernate升级到3,spring也换到最新了。目前发现一个很奇怪的现象，就是sSdm这种属性不能被解析，而只能解析为SSdm，hibernate和displaytag都有这个问题，看来是ognl的一个规则吧。目前为了兼容以前的数据库，只能从表生成类，我再加上关联。这样的类非常的难看，可以说是这次项目最大的缺憾阿。

我以后就钻们搞技术搞了一个很牛的东西出来之后阿，我就去做商务
把自己做的东西啊，卖掉
你看比尔盖茨就是这么发财的。

以后也许还可以用hibernate换掉jdbc的实现。目前感觉没有大问题。今天感冒，头疼。唉。我可不能死啊，好日子还没过呢。

webwork还是不够熟悉，用了spring和webwork,好容易才搞定了验证问题和i18n的显示，都是一些细节问题。

唉。千怕万怕还是出错拉，下午再联系现场，搞不好还是要跑一趟，真是麻烦啊。