两年的技术经历，在J2EE上疑惑

2.架构是就软件平台的搭建和设计规划，目的是实现软件最大的可维护性和可拓展性，延续软件的生命，就象人生下来，整个架构都有了，虽然一些器官不能用到（例如生殖器官），但是一生下来还是有这些器官，这就是架构设计的优势，没有架构设计的软件是看不到明天，生下的小孩就不会有生殖器官，因为他认为小孩不需要，但是他没有看到小孩20岁以后的未来。

架构就是要有预见性，特别是Java世界，技术流派众多，优劣共存，让人吃药的技术比比皆是，不象微软世界，有微软这个专制强权的架构设计者和提供者告诉你用什么，除此之外别无选择，在Java自由世界，你可能不小心走上一个不归路，软件架构一旦错误，就象出发的方向发生问题，南辕北辙成语就是说这个意思，花再多精力再多钱，再强的人都没有用，项目照样失败。

所以，在Java世界选择技术，就象女孩子到自由市场淘货，必须冒被骗失败的风险，但是其中乐趣也是不言而喻的，你会成为技术专家，当然，如果你想很多找到合适的架构设计，那么借助外力，象J道都提供这样架构设计服务，可以在短时间介绍一些这个自由市场哪些东西是性价比好，值得买，找个有信誉的内行当地人做咨询，就是这个道理。

目前Java世界，架构设计主要是框架选择，如果你的团队非常弱，可能只会基础的Java编程，那么选择强制性框架就比较好，这样可以在保证软件质量情况下，不让不太懂的人胡作非为，破坏软件整体的可维护性，好的框架甚至只需要XML配置就可以，这样，OO能力差一些人，就不需编程代码，配置配置XML就可以，这样，通过架构设计，可以充分发挥现有人员的长处，克服他们的短处。

所以，为什么过去数据库专家DBA年薪20万，而现在架构师年薪20万。而且DBA年薪20万已经成为过去时，因为人们已经发现，再好的数据库设计，只是数据库设计，不是程序语言设计，更多维护烦琐和复杂工作我们是需要修改的程序代码，所以，大家才开始重视应用程序代码，并且发现程序代码控制比数据库设计更难控制，所以有了OO体系专门对付程序代码，进而有了框架，从而诞生比DBA更重要的architect了。

3.关于struts重要性，还是必须从程序代码可维护性来讲，也就是从OO角度讲，Struts能够通过MVC模式将表现层进行细分，实现表现层内部各个细分部分的最大解耦，然后，Struts也可以将页面离散无规律的数据转变为对象，供业务层服务，也就是Struts表现层实际是业务层的服务者，为其提供对象化的枪支弹药，而业务层则可以围绕这些对象实现对象化编程，从而实现更好的可维护性，Evans DDD对业务层进行细分，这些都是基于对象基础，当然持久层不用说，和表现层一样也是业务层的服务者，为其提供对象化的枪支弹药，不过这些对象是从数据库里拿来的，是从一个非对象化，离散的、关系型的数据库拿来的，Hibernate等框架必须将他们转为对象，给业务层使用。

所有这些框架，都是保证我们业务逻辑完全OO，这个前提是：你相信只有OO才是目前实现软件最大维护性和拓展性的适当方式，虽然可能不是最好的，但他是目前最合适的，否则全世界软件工业不会花这么多力气在OO上了。

因为我们国内将软件看成数学，软件论文实际是数学公式论文，可以发生了软件研究方向的偏离，没有走上OO正确研究方向，这样导致很多程序员学校毕业后，根本没有OO基本意识，甚至有人抵触OO，我从出版社内部销售资料看到：Foxpro等数据库书籍名列销售前列，我是欲哭无泪，中国人的软件误区中还要走多少年。

所有这些，必须从我们教育体系寻找，这里面话题太多，我想其中一个问题还是：中微软毒太深，因为微软已经帮你做了架构的事情，你唯一要做的就是拿来某个软件，按照其说明书做，但是为什么这么做，几乎没有人去研究。

长此以往，很多人就根本没有了去探索的想法，安之罗素了，然后开始研究数学了，认为数学越奥深，软件就好，数学只是算软件服务的众多专业领域的一个领域，软件可以服务于管理专业、物流专业、银行专业、财会专业等等，软件可以服务这么多领域专业，那么软件本身应该如何做才是专业的呢？就是软件的可维护性和可拓展性，你必须活得够长，为你的主人服务，如果你一开始没有生殖器官，那么20岁以后你不是没用了，人就此绝种了？

软件绝种就是重新开发一套新的系统，这样做，对它所服务对象的杀伤力是很大的，国外大型企业信息主管已经深有体会：硬件落后了，我可以花更多钱替换，但是软件不能彻底替换，只能在其原来基础上延伸，但是如果发现这个软件不能延伸，就是请bill gates来，也没有用，那么这种损失是无以伦比，不能用金钱衡量的，这就是软件架构失败带来的损失。

因为我们国家长期来都是国有经济，能够活上百年的民营企业不多，国有银行等大型企业因为开始就请外国人做咨询，虽然也有彻底换软件的痛苦，但是有强有力国外厂商这些过来知道，弯路就是有不会太大。很多大型企业也是近期才上MRP或者ERP，民营企业基本都靠低廉的劳动力存活，不是靠管理，所以软件对于他们没有起到重要作用，所以，因为软件架构问题暴露的社会问题不会大规模出现，但是，如果不重视，迟早会出现。

我本人因为做得比较早，经历过因为不注重软件架构，导致方向错误，最后项目失败了才明白得经历。所以希望通过J道这样地方，呼吁更多人重视架构。

但是，现在又有一种现象：有些人嘴上架构框架很熟悉，但是实现起来代码还是乱糟糟，根本不是OO，这就象练武功的人，如果不经过有经验老师的点拨，靠自己看书，就会十分业余，具体表现就是嘴上功夫行，实际做起来不行，也就是他没有将理论和实践联系起来，就差这个窗户玻璃纸捅破，需要别人帮助，所以我提供培训咨询服务，没有教授高深知识，就是帮助你捅破窗户纸，但是，靠自己，什么时候能通，说不定呢，项目不等人，当然经常来Jdon论坛也可以看到大家这方面讨论。

说太多，有感而发，个人意见，仅供参考。

所以，在Java世界选择技术，就象女孩子到自由市场淘货，必须冒被骗失败的风险，但是其中乐趣也是不言而喻的，你会成为技术专家，当然，如果你想很多找到合适的架构设计，那么借助外力，象J道都提供这样架构设计服务，可以在短时间介绍一些这个自由市场哪些东西是性价比好，值得买，找个有信誉的内行当地人做咨询，就是这个道理。"
-------彭老大这番话说到点子上了,学Java可以成为技术专家,学.Net可以成为赚钱专家:)

在这样的背景下，SUN公司提出了J2EE（企业版 java 平台 ）,它是一个解决方案，一个能够构建复杂企业应用并能满足扩展性、性能、安全性的java解决方案。如果该解决方案得到认可，那么将实现开发商降低成本，减少响应时间的目标。所以SUN提出J2EE目标很明确:
1.满足企业应用的高要求
2.降低开发商的成本
3.减少开发商的响应时间
为了实现上述目标,SUN对J2EE方案进行了定义（即J2EE规范），在J2EE1.4采用了分层体系，提出了容器和构件的概念，并明确了容器的职责、构件的职责及如何一齐协调运作，它在其中运用了JSP、XML、EJB、JTA、JDBC等13种技术。
无可非议，该解决方案能够迎合企业应用的高要求、高复杂度。所以该解决方案得到了广泛的认可，形成了潮流，出现了中间件开发和构件开发的概念。
中间件开发商按照J2EE规范进行容器开发，如WEBSPHERE 、WEBLOGIC 、JBOSS，构件开发商按J2EE规范专心开发业务构件，然后部署到中间件中形成应用。