Java编程开发最容易出错的五大误区

越来越多人初步运用Java，可是他们大多数人没有做好满足的思维准备(没有承受完善的相关体系操练)，致使不能很好驾御Java项目，乃至导致开发后的Java体系功用缓慢乃至常常当机。许多人觉得这是Java杂乱导致，其实根柢原因在于:咱们原先掌握的软件常识不是太匮乏就是不恰当，存在认识上和办法上的误区。
　　软件的生命性
　　软件是有生命的，这或许是老调重弹了，可是因为它事关分层架构的原由，重复侧重都不过火。
　　一个有生命的软件首要有必要有一个活络可扩展的根底架构，其次才是无缺的功用。
　　现在许多人对软件的思维仍是焦点落在后者:无缺的功用，觉得一个软件功用越无缺越好，其实要害仍是架构的活络性，就是前者，根底架构好，功用添加仅仅时间和作业量问题，可是假定架构欠好，功用再无缺，也不或许包括未来全部功用，软件是有生命的，在未来生长时，更多功用需求参加，可是因为根底架构不活络不能便利参加，死路一条。
　　正因为普通人对软件存在短视误区，对功用寻求高于根底架构（orLysoft），许多吃了亏的老程序员就此脱离软件职业，带走贵重的失利经历，新的盲目的年青程序员仍是运用老的思维往前冲。其实许多国外免费开源结构如ofbiz compiere和slide也存在这方面骗局，形似非常契合胃口，其实类似国内那些几百元的盗版软件，扩展性以及持续发展性严重不足。
　　那么挑选现在一些盛行的结构如Hibernate、Spring/Jdonframework是否就标明根底架构打好了呢?其实还不尽然，要害仍是取决于你怎样运用这些结构来树立你的事务体系。
　　存储进程和杂乱SQL句子的骗局
　　首要谈谈存储进程运用的误区，运用存储进程架构的人认为能够处理功用问题，其实它正是导致功用问题的元凶巨恶之一，打个比如:假定一个人频临逝世，打一针能够让其延伸半年，可是打了这针，其他全部医疗计划就全部失效，请问你会运用这种短视计划吗?
　　为什么这样说呢?假定存储进程都封装了事务进程，那么作业负载都会合在数据库端，要中心J2EE应用服务器干什么?要中心服务器的分布式核算和集群才调做什么?只能回到早年会合式数据库主机时代。现在软件都是面向互联网的，不象早年那样约束在一个小局域网，多用户并发拜访量都是无法确定和衡量，依托一台数据库主机显然是不能够承受这样恶劣的用户拜访环境的。(当然搞数据库集群也仅仅五十步和百步的差异)。
　　从分层角度来看，现在三层架构:体现层、事务层和耐久层，三个层次应该切开明显，责任清楚:耐久层责任耐久化保存事务模型政策，事务层对耐久层的调用仅仅帮助咱们激活早年托付其保管的政策，所以，不能因为耐久层是保管者，咱们就以其为中心盘绕其编程，除了要求其偿还模型政策外，还要求其做其做杂乱的事务组合。打个比如:你在火车站将生果和盘子两个政策托付保管处保管，过了两天来取时，你还要求保管处将生果去皮切成块，放在盘子里，做成生果盘给你，合理吗?
　　上面是谈过火依托耐久层的一个现象，还有一个正好相反现象，耐久层宣布出来，初步挤占事务层，腐蚀事务层，整个事务层处处看见的是数据表的影子(包括数据表的字段)，而不是事务政策。这样程序员应该多看看OO经典PoEAA。PoEAA 认为除了耐久层，不应该在其他当地看到数据表或表字段名。
　　当然适量运用存储进程，运用数据库利益也是容许的。按照Evans DDD理论，能够将SQL句子和存储进程作为规矩Specification一部分。
　　Hibernate等ORM问题
　　现在运用Hibernate人也不少，可是他们发现Hibernate功用缓慢，所以寻求处理计划，其实并不是 Hibernate功用缓慢，而是咱们运用办法发生过错:
　　“最近自己正搞一个项目，项目中咱们用到了struts1.2+hibernate3, 因为联络杂乱表和表之间的联络许多，在许多当地把lazy都设置false，所以导致数据一加载很慢，并且查询一条数据更是非常的慢。”
　　Hibernate是一个根据政策模型耐久化的技能，因而，要害是咱们需求规划出高质量的政策模型，遵照DDD范畴建模准则，减少降低相关，通过火层等有用办法处理相关。假定采用盘绕数据表进行规划编程，加上表之间联络杂乱(没有科学办法处理、侦查或减少这些联络)，必定导致体系作业缓慢，其实相同问题也适用于初步对EJB的实体Bean的CMP诉苦上，实体Bean是Domain Model耐久化，假定不首要规划Domain Model，而是规划数据表，和耐久化东西规划政策各走各路，能不出问题吗?关于这个问题N多年就在Jdon争论过。
　　这儿相同延伸出其他一个问题:数据库规划问题，数据库是否需求在项目初步规划?
　　假定咱们进行数据库规划，那么就发生了一系列问题:当咱们运用Hibernate结束耐久保存时，有必要考虑事前规划好的数据库表结构以及他们的联络怎样和事务政策结束映射，这实践上是非常难结束的，这也是许多人觉得运用ORM结构扎手根柢原因地址。
　　当然，也有脑力适当兴隆的人能够结束，可是这种盘绕数据库结束映射的效果必定误解事务政策，这类似于两个板块(数据表和事务政策)相撞，必定发生地震，地震的效果是玉石俱焚，软的一方吃亏，事务政策是代码，适当于数据表结构，归于软的一方，究竟导致事务政策变成数据传输政策DTO, DTO满天飞，功用和维护问题随之而来。
　　范畴建模处理了上述许多不协调问题，特别是ORM痛苦运用问题，关于ORM/Hibernate运用仍是那句老话:假定你不掌握范畴建模办法，那么就不要用Hibernate，关于这个层次的你:或许No ORM 更是一个简略之道: No ORM: The simplest solution
　　Spring分层敌视问题
　　Spring是以应战EJB容颜呈现，其本身具有的强健组件定制功用是利益，可是存在实战的一些问题，Spring作为事务层结构，不支撑事务层Session 功用。
　　详细举例如下:当咱们结束购物车之类事务功用时，需求将购物场合保存到Session中（prassLLp），因为事务层没有便利的Session支撑，咱们只得将购物车保存到 HttpSession，而HttpSession只需通过HttpRequest才调获得，再因为在Spring事务层容器中是无法拜访到HttpRequest这个政策的，所以，究竟咱们只能将“购物车保存到HttpSession”这个功用放在体现层中结束，而这个功用明显应该归于事务层功用，这就导致咱们的Java项目层次紊乱，维护性差。违反了运用Spring和分层架构初步目的。
　　范畴驱动规划DDD
　　现在回到咱们谈论的重点上来，分层架构是咱们运用Java的根柢原因之一，域建模专家Eric Evans在他的“Domain Model Design”一书中开篇首要侧重的是分层架构，整个DDD理论实践是奉告咱们怎样运用模型政策oo技能和分层架构来规划结束一个Java项目。
　　咱们现在许多人知道Java项目根本有三层:体现层　事务层和耐久层，当咱们顽固于谈论各层结构怎样挑选之时，实践上咱们实在的项目开发生业还没有初步，就是咱们选定了某种结构的组合(如Struts+Spring+Hibernate或Struts+EJB或Struts+JdonFramework)，咱们还没有意识到事务层作业还需求许多作业，DDD供应了在事务层中再差异新的层次思维，如范畴层和服务层，乃至再细分为作业层、才调层、战略层等等。通过层次细化办法抵达杂乱软件的松耦合。DDD供应了怎样细分层次的办法。
　　当咱们将精力花费在架构技能层面的谈论和研讨上时，咱们或许忘记以何种根据挑选这些架构技能?挑选标准是什么?范畴驱动规划DDD 回答了这样的问题，DDD会奉告你假定一个结构不能帮助你结束分层架构，那就扔掉它，一起，DDD也指出挑选结构的考虑目的，使得你不会随声附和，堕入杂乱的技能细节迷雾中，迷失了架构挑选的根柢方向。
　　现在也有些人误认为DDD是一种新的理论，其实DDD和规划形式相同，不是一种新的理论，而是实战经历的总结，它将前人运用面向模型规划的办法经历提炼出来，供后来者学习，以便敏捷找到驾御咱们软件项目的根柢之道。从许多方面都能够看出Java在整个软件业先进思维的实践上总是抢先一步，在这儿就不多说了。