Java软件开发中可能出现几个错误观点

原文：http://blog717171.blog.163.com/blog/static/250603111201511904934806/

愈来愈多人开始使用Java，可是他们大多数人没有作好足够的思想准备(没有接受OO思想体系相关培训)，以至不能很好驾驭Java项目，甚至 致使开发后的Java系统性能缓慢甚至常常当机。不少人以为这是Java复杂致使，其实根本缘由在于：咱们原先掌握的关于软件知识(OO方面)不是太贫乏就是不恰当，存在认识上和方法上的误区。

软件的生命性

软件是有生命的，这多是老调重弹了，可是由于它事关分层架构的起因，反复强调都不过度。

一个有生命的软件首先必须有一个灵活可扩展的基础架构，其次才是完整的功能。

目前不少人对软件的思想仍是焦点落在后者：完整的功能，以为一个软件功能越完整越好，其实关键仍是架构的灵活性，就是前者，基础架构好，功能添 加只是时间和工做量问题，可是若是架构很差，功能再完整，也不可能包括将来全部功能，软件是有生命的，在将来成长时，更多功能须要加入，可是由于基础架构 不灵活不能方便加入，死路一条。

正由于普通人对软件存在短视误区，对功能追求高于基础架构，不少吃了亏的老程序员就此离开软件行业，带走宝贵的失败经验，新的盲目的年轻程序员 仍是使用老的思惟往前冲。其实不少国外免费开源框架如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

http://www.theserverside.com/blogs/thread.tss?thread_id=41715

Spring分层矛盾问题

Spring是以挑战EJB面貌出现，其自己拥有的强大组件定制功能是优势，可是存在实战的一些问题，Spring做为业务层框架，不支持业务层Session 功能。

具体举例以下：当咱们实现购物车之类业务功能时，须要将购物场合保存到Session中，因为业务层没有方便的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和设计模式同样，不是一种新的理论，而是实战经验的总结，它将前人 使用面向模型设计的方法经验提炼出来，供后来者学习，以便迅速找到驾驭咱们软件项目的根本之道。