＋设为首页 ＋添加到收藏夹
最近参与了一个严重依赖ejb技术,针对某特定领域的软件产品.由于该领域的业务逻辑种类复杂繁多,ui层无法做到非常简单,同时数据的采集.提交与表现也非常复杂,因此该产品使用了cs架构,通过一个胖客户端连接ejb中的业务逻辑接口,然后由ejb负责调用下层的dao等完成处理过程.
在开发初期中,因为涉及到的业务量较小,因此基本上若客户端需要某个功能,ejb层肯定有相应的功能接口及其实现.换而言之,ejb层本身就不是面向对象的,所有的功能都零散地分布在各个ejb中.例如一个叫做customer的ejb提供了客户购买产品.退货.更换等逻辑的实现,一个叫做product的ejb提供了产品定义.价格定义等逻辑的实现. 【程序编程相关:J2ME学习笔记（六）】 由于ejb本身就是重量级的侵入型框架,在一定程度上阻碍了面向对象设计,同时开发人员对ejb接口功能划分的问题也并没有足够重视,只是本着“先运行再重构”的简单想法进行了接口功能粒度的划分. 【推荐阅读:通过了SCJP，个中经验和体会写在这里】 幸好,由于有完备的文档支持,整个项目没有失控,各个ejb虽然越来越大,越来越“面向过程”,但整体的功能实现还是得到了保证.最终项目验收的时候,虽然整个软件不“很好看”,但也在功能.速度与成本方面达到了基本要求. 【扩展信息:classloader讲解】 当软件开发进行到后期的时候,由于业务量越来越大,各个ejb也变得越来越臃肿与庞大,一个ejb里面常常塞满了看起来差不多,但又不完全一致的方法——整个ejb层成为一个包罗反象.无所不能却又混乱不堪的怪物. 漫长的维护期开始了……... 下一页