解析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基础架构之于具体开发的多种硬性限制,相信这种做法是必要的，期待大家讨论。

 

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

 

 

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

2.5有注解

@Autowired
CustomerDao customerDao;
这样注入

-------------
一看就是高手哦，呵呵。

这里只是谈一种现象，一种思维，j2ee领域有种思维僵化的倾向，需要改革开放，呵呵。最近帮别人做架构评估，有感而发，看完是一声叹息。。。

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

写了个静态interface
需要用到的key都放在这个interface中
所以几乎不太可能写错单词.....
不过维护很麻烦
现在里面还有些key不知道能不能删.

大小写不敏感
---------可在已有的Map上封装自己的处理实现大小写不敏感的Map.

现在里面还有些key不知道能不能删.
---------目前没什么特别好的办法，一般可考虑对key进行良好的注释和管理维护。

上面描述的场景主要是通过Map/bean对具体业务数据的承载，key是可变的不可预知的，然后在页面进行数据展现。

所以我们的办法是对Map/beanUtils/spring进行了一定得扩展。

我们在框架中各个层面实现了业务数据的大小写不敏感访问，大小写不敏感是整个框架的一个基本契约。