解析java web开发中的困扰(1)

诸如jsp等脚本性质的语法、基于xml的属性配置与属性注入在j2ee开发中大量使用,而这些语法都是编译期不敏感的,

也就是说这类错误只有在运行时才能发现,这一局限对j2ee的开发造成了很大的困扰。相信大家都是深有体会!!

 

期望在编译期发现这些错误目前还不太现实,即使要做也要开发一个类似的java预编译器,抑或依赖IDE的智能检测机制(Intellij Idea在这方面做的较好,eclipse系列支持较弱),代价还是蛮昂贵的。

 

java web开发领域之所以如此现状,并不是java web领域的基础架构有问题,相反java开源架构层出不穷,大多数是极其优秀的,对于基础架构来说这些限制是必要的。本人认为问题在于java领域的2线架构师(应用架构师)水平低劣,没有在基础架构上做足够的润色,抑或根本没有分析出开发效率低下的原因所在。

 

所以大家应该反省一下目前的“拿来主义”存在的问题了!!拿来+润色+定制+契约===符合特定问题域的优秀架构,效率彰显的架构。

 

举个具体的例子:

 

spring的属性注入时严格依赖get/set;

 

Beanutils在web开发中使用非常频繁,属性访问,数据转换....

Beanutils在进行属性copy时遵循java bean规范,并严格区分大小写,这个规则在开发中消耗大量的调试时间,

具体大家可以仔细想一想就明白了,它的影响绝对超过你的第一反应。如果能对它进行一些扩展和定制,可想而知带

来的效率提升是很客观的。

 

        再一个例子就是Map的访问键,如果能做到大小写不敏感(之前的文章中有实现办法)....................

 

        在我们的EAP框架中对于此类问题作了很好的扩展,规避了java web基础架构之于具体开发的多种硬性限制,相信这种做法是必要的,期待大家讨论。

 

        后续还会有类似问题与大家交流。

 

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值