23,405
社区成员
发帖
与我相关
我的任务
分享工作一年了，感到技术该更新了，可一时迷茫不知从何做起
07年大三进的这家公司实习，08年毕业留在公司，至今在公司两年了。刚进公司那会只会写vb、asp,公司开发用c#，自己自学了一个月,能帮他们做些边边角角的工作。后来公司让我帮美工做Demo，我就帮着做，期间接触了JavaScript比较喜欢，一直坚持学习至今，现在我几乎负责公司所有的JS脚本。老实说自己JS水平也很一般但公司没人会所以只能我来做了.学习两个月后公司换Java平台使用普元的Eos5.6做开发，同事教我用Eclipse，并让我写写简单JspTag，让我看看工厂模式等常用的设计模式,也学会了使用反射、正则表达式、在Java中执行javascript脚本,因为公司用Eos不熟悉SSH这些流行框架只看过几段Struts2源码写过几个HelowWorld程序，感觉不是很难。
现在的情况是我能在Google的帮助下完成他们交给我的工作，但是由于是自己自学的，好多东西都路子比较野，知识也不扎实
好多时候都是看论坛别人说道一个名词才知道java里边还有这个。而且好多东西写得快忘得也快，隔写天再拾起来还需要重新Google下相关的知识。
总的来说，自己还是有些自学能力的，可是J2EE太庞大了,有心想系统补充下知识但一时不知道从那看起。论坛中肯定不乏有资历有经验的前辈，想听听大家的建议。
现在的情况是我能在Google的帮助下完成他们交给我的工作，但是由于是自己自学的，好多东西都路子比较野，知识也不扎实
好多时候都是看论坛别人说道一个名词才知道java里边还有这个。而且好多东西写得快忘得也快，隔写天再拾起来还需要重新Google下相关的知识。
总的来说，自己还是有些自学能力的，可是J2EE太庞大了,有心想系统补充下知识但一时不知道从那看起。论坛中肯定不乏有资历有经验的前辈，想听听大家的建议。
...全文
请发表友善的回复…
发表回复
greatmind829 2010-02-07
- 打赏
- 举报
努力吧！
我出是刚进公司不久。
有得学的了。
我出是刚进公司不久。
有得学的了。
bsbbt 2009-11-26
- 打赏
- 举报
我读大三的时候开始学j2ee，现在出来工作差不多一年了，最近在做报表导出功能，感觉好吃力！！
zhilesjf 2009-11-04
- 打赏
- 举报
嘿嘿。。。。我要认真学啊！！
xingqiliudehuanghun 2009-07-30
- 打赏
- 举报
已经结贴很长时间了，没想到大家这么热心。要是csdn能让几个大牛就这个题目写个专题就好了，
毕竟有不少人面临这个问题
毕竟有不少人面临这个问题
DreamStyle 2009-07-06
- 打赏
- 举报
学习中,.......
谈阿大 2009-06-15
- 打赏
- 举报
我和楼主一样，毕业开始用ASP.net 5月刚开始用SSH框架写JSP 写的还行，里面的一些基础的东西不怎么会～遇到问题也就是Google一下看看例子的代码大致能知道做什么了～
mastic 2009-06-15
- 打赏
- 举报
如果自信的话,请加入我们
我们一向致力于企业信息化推广,由国内知ERP软件公司出来.拥有成熟的客户群体.
现已将前期市场需求进行了调研,将转化为产品化阶段,我们整合各方面资源,目前以落实可以测试的样板用户.
现寻求技术合作伙伴,
要求居住在上海地区.有事业心,勇于承担压力,同我们一起同甘共苦,创业奋斗.
我们不考虑学历,只在乎能力,懂VB等语言数据库开发,承担过中型购销存,CRM等管理系统开发工作
只要您有信心并能胜任,都愿意接受为我们团队的一员.
相信在各位领导和客户的支持下,您会和我们一起成长,进步的.
您的简历请邮件请发:ledtalk@126.com 注明技术合作伙伴,我们会尽快同您联络面谈.
我们一向致力于企业信息化推广,由国内知ERP软件公司出来.拥有成熟的客户群体.
现已将前期市场需求进行了调研,将转化为产品化阶段,我们整合各方面资源,目前以落实可以测试的样板用户.
现寻求技术合作伙伴,
要求居住在上海地区.有事业心,勇于承担压力,同我们一起同甘共苦,创业奋斗.
我们不考虑学历,只在乎能力,懂VB等语言数据库开发,承担过中型购销存,CRM等管理系统开发工作
只要您有信心并能胜任,都愿意接受为我们团队的一员.
相信在各位领导和客户的支持下,您会和我们一起成长,进步的.
您的简历请邮件请发:ledtalk@126.com 注明技术合作伙伴,我们会尽快同您联络面谈.
yhy1987 2009-06-15
- 打赏
- 举报
也来学习一下了！
nickhond 2009-06-15
- 打赏
- 举报
帮顶
luofuyan 2009-06-14
- 打赏
- 举报
楼主你的技术分好高啊
vivdaxiang 2009-06-14
- 打赏
- 举报
楼主的技术分好高啊啊
huangwei913 2009-06-14
- 打赏
- 举报
帮不上忙 不过路过帮顶
hbsdtxz 2009-06-14
- 打赏
- 举报
学习了！
virtual_prosperity 2009-06-14
- 打赏
- 举报
[Quote=引用 15 楼 zhenyuanc 的回复:]
顶Ajax，JavaScript学深了也很牛的。
套想系统学Java就买本Java基础的书，其实很简单的，你应该学很快。学完了就可以看J2ee方向的开发，先学习servlet+jsp，然后看看struts1，和struts2.熟悉了就可以研究struts：1or2 + hibernate3.1 + spring2.0的整合开发了。
[/Quote]
定一个，谁说学Java就先要去学C
顶Ajax，JavaScript学深了也很牛的。
套想系统学Java就买本Java基础的书，其实很简单的，你应该学很快。学完了就可以看J2ee方向的开发，先学习servlet+jsp，然后看看struts1，和struts2.熟悉了就可以研究struts：1or2 + hibernate3.1 + spring2.0的整合开发了。
[/Quote]
定一个，谁说学Java就先要去学C
yearfree 2009-06-14
- 打赏
- 举报
我觉得还是把c、数据结构学通了，其他都是相通的
sxffff 2009-06-14
- 打赏
- 举报
现在大型J2EE项目中必备的：
1. Rule Engine
2. Process Engine
3. implement Single sign on
4. Role Base Security Framework
5. Validation Framework
6. intergration Framework
7. Task creation and manager Framework.
8. UI。
1. Rule Engine:
Rule Engine 是复杂商业中比较常用的。 通常POJO中的值都必须可以apply Business rule。好的Rule Engine是应该可以让BA 直接写Rule而不需要由Developer写。例如银行业务中，那一类人可以获得免月费，银行本月的promotion是针对那一类客户。Rule 要能实现version control。能根据时间把相对应的Rule找回来。
2. Process Engine
简单的MVC已经不能满足需求了。提供一个工具给高级的BA把商业流程画出来，Process Engine自动处理，Transaction Control 应该在USER Action之间。理论上说，流程的更改，不需要Developer 参与。
3. 不需要多说。
4. 提供UI定义Role与Role之间的关系。根据用户的Role，能轻松地定义网页上每一个Object 的属性。例如：是否显示， 可否更改。显示的顺序。Base On Role，Process 也应该相应地更改。最好能跟Email系统或手机系统集成。
5. 好的Validation Framework 应该能Validate 所有的数据（Base On the Whole DateModel)。
6. intergration Framework
必须能跟SAP，CRM， MainFrame 系统Intergrate。
如果用户是从旧系统转到新系统, 还必须跟旧系统集成。
7. 能够建立Task，每个Task有Listener，建立Notification 系统。 对于每个Task，提供跟踪系统，提供实现Task每个Step所需要的东西。
8. 好的UI。不能次于EXT。
建议：
不要再学基础了，学一点最新的东西吧。
1. Rule Engine
2. Process Engine
3. implement Single sign on
4. Role Base Security Framework
5. Validation Framework
6. intergration Framework
7. Task creation and manager Framework.
8. UI。
1. Rule Engine:
Rule Engine 是复杂商业中比较常用的。 通常POJO中的值都必须可以apply Business rule。好的Rule Engine是应该可以让BA 直接写Rule而不需要由Developer写。例如银行业务中，那一类人可以获得免月费，银行本月的promotion是针对那一类客户。Rule 要能实现version control。能根据时间把相对应的Rule找回来。
2. Process Engine
简单的MVC已经不能满足需求了。提供一个工具给高级的BA把商业流程画出来，Process Engine自动处理，Transaction Control 应该在USER Action之间。理论上说，流程的更改，不需要Developer 参与。
3. 不需要多说。
4. 提供UI定义Role与Role之间的关系。根据用户的Role，能轻松地定义网页上每一个Object 的属性。例如：是否显示， 可否更改。显示的顺序。Base On Role，Process 也应该相应地更改。最好能跟Email系统或手机系统集成。
5. 好的Validation Framework 应该能Validate 所有的数据（Base On the Whole DateModel)。
6. intergration Framework
必须能跟SAP，CRM， MainFrame 系统Intergrate。
如果用户是从旧系统转到新系统, 还必须跟旧系统集成。
7. 能够建立Task，每个Task有Listener，建立Notification 系统。 对于每个Task，提供跟踪系统，提供实现Task每个Step所需要的东西。
8. 好的UI。不能次于EXT。
建议：
不要再学基础了，学一点最新的东西吧。
qqshs 2009-06-14
- 打赏
- 举报
我情况有点和你差不多,
我是先学struts,有了比较好的基础后,就可以学习spring,
而且学习时,先把基本的撑握,会用,比如,struts的基本使用配置,struts标签的使用,
然后看点MVC理论知识.在学SPRING时,明白是什么IOC,会配置SPRING BEAN,并且懂得如何注入.
学会这些后,基本上你就入门了,接下来就慢慢的研究自学,比如SPRING AOP,比并且再看些理论的资料.明白其中的原理.
我是先学struts,有了比较好的基础后,就可以学习spring,
而且学习时,先把基本的撑握,会用,比如,struts的基本使用配置,struts标签的使用,
然后看点MVC理论知识.在学SPRING时,明白是什么IOC,会配置SPRING BEAN,并且懂得如何注入.
学会这些后,基本上你就入门了,接下来就慢慢的研究自学,比如SPRING AOP,比并且再看些理论的资料.明白其中的原理.
cindyaita 2009-06-14
- 打赏
- 举报
我小弟一个，经验就不谈了，帮顶吧！
qq375002446 2009-06-14
- 打赏
- 举报
送你一篇我正在写的一本电子书的第一张吧,仅供参考
希望你能把分给我哈
序言言:步履江湖观大略
――从宏观上了解Web应用程序
现实因素是改变一切的根源――王兴刚。
进入九十年代中后期,随着互联网的兴起，人们强烈希望应用程序的使用，能够像浏览网页一样愉快。而传统的C/S结构应用程序，要求每一个使用者，必须在自己的计算机上安装一个客户端软件，没有这个软件，就没有办法访问位于服务器上的应用程序。因此C/S结构的笨拙，与广大人民群众日以增长的简单需求之间，产生了深刻的现形矛盾，因此，也就无法适应这个时代的历练，从而，渐渐地退出了程序开发的历史舞台。
应用程序与C/S结构一揖而别，转而投向了B/S的怀抱。应用程序的开发迎来了Web时代。作为Web应用程序领头雁的java，最开始的web应用，是以Applet（小应用程序）的方式出现的。当时的应用形式是，在服务器上发布的小应用程序，当被浏览器访问时，被下载到客户的计算机上运行。这就造成了安全上的隐患。比如，如果Applet（小应用程序）内部包含有数据库的Url，用户名，密码等敏感信息，当Applet被下载到本地以后，随便找个反编译工具，很容易地就能获取到Applet的原代码，甚至比一些垃圾程序员书写的程序更符合编码规范。当此之时，只要不是傻子都能看明白数据库的连接信息。这就等于告诉小偷：“我刚取了50万银子在家里放着呢，家里没有人，门没有锁，我也没有养狗的习惯！”。如果小偷不到你家去做客，那是他人品有问题。
仔细分析Applet的不安全性，我们发现，原因在于Applet是在客户端运行的。基于安全性考虑，人们希望java程序能从客户端走向服务器端。程序在服务器上运行，不被下载到客户端计算机上。此时出现的第一门技术是Servlet，它很好地满足了人们对java安全性的要求。但是接下来的问题是，由于Servlet对所有用于客户端显示的网页代码，都要在服务器端完成，也就是Servlet不但要完成服务器端流程的调度，还要负责页面的实现，而原本简洁的Html一旦在Servlet内部完成，就变得极其繁琐，这给开发过程带来了新的麻烦，严重影响了开发效率，从而影响了Servlet的大面积推广使用。
此后不久，Sun也终于认识到自己有点太CNN了，于是出于简化Servlet应用的目的，推出了新一代Web应用技术规范，这就是JSP规范。JSP通过在html内部嵌入java代码的方式，很好的解决了Servlet对页面显示的实现过于复杂这个难题，让web程序开发进入了一个崭新的时代。然而，倒霉的Sun公司又陷入了新的问题之中。什么问题哪，我们需要好好地思考软件开发过程中的“逻辑问题”。
就个人观点而言，一个web应用程序应该包括三个方面的逻辑，这就是：显示逻辑――负责页面的展现；控制逻辑――负责流程的调度，也就是调用哪个类进行数据处理，数据运算，调用哪个页面，将运算生成的数据显示出来。业务逻辑――这里指的就是复杂繁琐的商业运算和数据处理了。
通过对JSP的分析，我们发现，其Html部分应该负责的是页面显示的内容，属于显示逻辑的范畴，而java脚本，主要负责的是数据运算以及数据处理，应该是属于业务逻辑的范畴。而Jsp没有对这两种逻辑进行很好的划分，从而造成显示逻辑与业务逻辑交织在了一起（这就是所谓的耦合度过高），给程序的测试过程以及后期的维护造成了很大的不便。于是，Sun公司的伟大程序员们，开始伴随着使用者的抱怨和缭绕的烟雾，进行了深刻且细腻的思考。
后来有一天，当一群程序员在苹果树下放松神经的时候，忽然间，来了一阵大风，满树的苹果像冰雹一样砸到了他们的脑袋上，也砸开了他们的视野，新的应用方式诞生了，从此真正开始了java在web应用程序开发过程中的辉煌之旅，并且一直到今天，依然笑傲江湖，环球不败！那么他们思考的是什么哪？
他们发现，针对三种逻辑，JSP的强项在于页面显示，可以用于处理显示逻辑；Servlet的强项是流程调度，可以将JSP中大量用于流程调度的语句提取出来，转而交给Servlet来处理，这样控制逻辑的问题也很好地解决了；那么业务逻辑怎么办哪？JavaBean除了用来封装数据，也可以有方法的啊，为什么不用JavaBean的方法来处理业务逻辑哪，没有理由啊！那就用呗。于是乎，业务逻辑的处理问题，也找到了合适的解决方案（后来，随着编程思想和变成艺术的提高，JavaBean与普通java类之间的关系日渐模糊，人们也更提倡使用没有任何规范的普通java类来处理业务逻辑，并且给他起了个名字，以便更好地提倡这种思想，这就是POJO――普通java类）。于是三种逻辑，各得其所。此后，围绕三种逻辑，在不同复杂程度的业务系统中的应用，产生了两种模式：Model1（JSP＋JavaBean）和Model2（JSP+Servlet＋JavaBean）。Model1比较适合于小规模的系统，比如网站等。而针对复杂的企业级应用（比如金融系统，社保系统等），Sun公司推荐使用Model2。
Model2出现以后，人们于实际应用过程中发现，其中的jsp关注的是页面显示，Servlet关注的是流程控制，而JavaBean关注的是业务处理。这与传统的MVC非常类似，传统的MVC包括了三个方面的内容，模型，视图，控制器。模型：关注数据处理；视图：关注数据显示和报表处理;控制器:负责协调模型和视图。因此，人们开始认为，Model2是基于MVC的。就个人观点而言，如果只是进行网站的开发，还是Model1方便。原因是什么哪？Model2有些复杂。
随着现代社会的发展，商业规则的复杂程度，已经超过了人们的想象。而刁瞒的客户是不管这些的，他们给我们的时间总量是固定的。而软件公司在与客户相处的过程中始终处于弱势地位，是没有太多发言权的，原因很简单，因为公司要盈利，我们要赚客户的钱！
客户限定了时间，也就限定了项目的周期。针对一个复杂的系统，在总量一定的情况下，我们总是在寻求技术时间与业务设计时间的最佳配比。在项目周期固定的情况下，技术时间与业务设计时间是成反比的。两者此消彼长，如果用于技术处理的时间长了，那么业务设计的时间必然就要缩短，同理，如果用于业务处理的时间要增加，就必须缩短技术处理的时间。而在两者的选择过程中，我们不得不选择缩短技术时间，原因很简单，业务规则越来越麻烦，客户并不跟你摆事实，讲道理。而Model2，虽然很好地解决了三种逻辑的划分，可以应用于企业应用程序开发，但是过于繁琐，实现的手法过于粗略。好多基础性的服务没有为我们提供。比如，请求的分发，请求过程中数据的获取等等。于是人们希望应用新的方式替换Model2，或是简化Model2的应用。基于此，大量基于Model2的web框架，如雨后春笋般诞生出来。其中最优秀的就是Struts1和WebWork。后来，两者实现了新的融合，形成了Struts2。由于他们都是基于Model2的，而Model2是基于MVC的，于是人们认为，他们都是基于MVC思想而产生的。
Struts1是第一个成熟的基于MVC的web框架。他的出现使Model2的应用得到了大大的简化，我们将在此后的章节中学习它，并且会发现他的简洁和优美。Struts1简化了Model2的应用，但是只是解决了企业级应用系统的Web层问题。那么企业应用系统还有那些层哪，为什么要有这些层哪，这些层又是用什么方式解决更好哪？
MVC的出现，到今天，已经有40年的历史了，面对复杂的现代商业规则，他已经有些苍老，而用它来解决今天的问题，就好像把秦始皇从地下扣出来，然后给他一个遥控器，说一句：“哥们，把电视机闭了！”。估计这哥们肯定龙颜大怒，回敬你一句：“拖出去，毙了！”。那么既然MVC苍老了，谁还年富力强哪，答案就是分层体系架构！
下面我们来看看贯穿后继章节的分层思想。
一个好的应用系统，一般都是基于分层体系结构来完成的。分层体系结构大致如下图所示：
其中的显示层，对应于MVC的视图（V），控制层对应的是MVC的控制器（C），在后继的章节中，我们将其合并到一起，统称Web层（也有的书上称为展示层）。而Struts只是解决了这里的WEB层的技术实现。其它层又是些什么哪，应用那些技术来实现哪？
随着商业规则复杂度的增加，数据处理也日渐繁琐，而数据库技术的诞生很好地解决了这个问题。可以说，今天的应用程序开发，基本上是离不开数据库的，无论是各种运算，处理，最后都要把数据存储到数据库中，以便于将来查询，或是进一步对数据进行分析和加工。这样程序设计的最终目的，也就转换为对数据库的检索，分析和更新。也就是最终都要把内存中的数据保存到某种数据库中，以便长久存储。这就是所谓的数据持久化。而数据持久层就是解决持久化的一个专用的系统逻辑层。目前来说，应用最为广泛的是Hibernate，他是事实上的数据持久化标准。还有，后继兴起的EJB3技术，也属于此范畴，其前途也是不可限量的。
当持久层技术出现以后，它与原先的模型是什么关系，在模型内部，它处于什么地位，怎么应用持久化技术，这些在原始的MVC中都没有给出明确的定义。这也是MVC思想过时的一个原因，它的模型概念过粗，过于笼统。而分层体系架构，对此作出了明确的定义。持久层，只负责解决数据的持久化（数据持久化对象的增删改查）问题，而为了更好地应用持久层，分层思想引入了业务逻辑层。这一层，一般而言就是普通的java类（POJO），它负责组合多个持久化组件，完成复杂的商业处理（比如利息计算，帐户结转，银行转帐等）。
在一个软件系统中，经常会有一些提供基础服务的类，比如GUID码的生成，MD5加密，四舍五入的处理，电子邮件的发送等等。我们发现他们为具体的业务处理提供了基础性的服务，但是，又不专署于任何一种特定的业务逻辑。为此，分层体系结构将其单独抽象出来，形成了系统服务层。这一层，一般而言，我们也应用普通Java类（POJO）来进行处理。
基于上述分析，我们可以看到，分层体系结构中，一般而言包括四个宏观的逻辑层次，分别是Web层，业务逻辑层，持久层和系统服务层。同时，分层体系结构还定义了它们的强制性调度关系：“同层和相邻层可以相互访问，不允许夸层访问”。比如，控制层，不能跨越业务逻辑层，直接访问持久层。
当分层体系思想出现以后，软件开发系统中的各个组件都有了合适的位置。我们可以高枕无忧地大步前行了。是不是真的这样哪？实践是检验一切的唯一标准，现实的因素决定一切技术和思维的生命周期！
在实际应用过程中，新的问题又出现了。
在完成复杂功能的同时，我们一直在追求着已有功能实现（组件）的复用。而复用的最佳途径是通过已有组件的组合，产生新的功能点。这就不可避免地涉及到组件之间的调用方式问题。传统的组件调用方式，是由应用程序自身管理组件之间的调用和组合，从而造成了组件之间的高耦合，给组件的独立测试和整个系统的后期维护带来了很大麻烦，使软件质量的提高一如镜花水月，无法真正地从技术上实现。同时，在面向对象思想的应用过程中，伟大的程序员们发现，面向对象只是解决了事物之间纵向的一脉相承，而对于诸如系统日志，安全支撑，事务管理等贯穿于整个系统所有功能点的横向公共性功能，没有给出很好的解决方案。为了解决上述问题，一个新的框架应运而生了，它就是Spring。在Spring中，通过DI（依赖注入）思想，很好地解决了组件之间的调度问题。同时，引入AOP（面向切面编程）很好地解决了公共性功能的处理问题。从而给软件开发，带来了一场深刻的，触及灵魂的革命，软件行业，迎来了真正的春天。
在本书的知识体系中，对于分层体系架构的实现，WEB层将采用Struts1.x,持久层将采用Hibernate。而对于整个架构各个组件之间的宏观调度和事务处理，将采用Spring2.x来完成。这就是目前比较流行的SSH整合架构设计。
上述对于数据持久化，分层体系结构，依赖注入等的论述，都只是简单的介绍，目的是让读者能从宏观上对分层体系结构及其SSH实现有个粗浅的了解，在后继的章节中，本书将会进行详细的阐述。不必着急，那样吃不了热豆腐，坚持下去，一切都会好起来。毕竟，人，活着就有希望！
事物都在经历一个从无到有，从弱到强的过程，受实践因素的影响，我们的认识总是停留在一定的局限上的，随着实践的深入，人们的编程思想和编程技术在不断成熟和发展，新的应用技术和方法也会逐步产生，从这个角度来说，浩茫广宇，存在着无数的新思想和新技术等待我们去发现和实现。而程序员的乐趣也正在于此：可以不断地接触新奇的世界，新奇的思想。胸含广宇，气象万千！
最后，演绎林锐先生的一段话，作为本篇的结束：
让我们高举JAVA主义、软件工程思想的伟大旗帜，紧密团结在以Sun公司为核心的软件巨头周围，沿着比尔·盖茨先生的生财之道，不分白天黑夜地吐血编程，把建设有中国特色软件产业的伟大事业，全面推向21世纪。构建和谐社会，享受大康人生！
希望你能把分给我哈
序言言:步履江湖观大略
――从宏观上了解Web应用程序
现实因素是改变一切的根源――王兴刚。
进入九十年代中后期,随着互联网的兴起，人们强烈希望应用程序的使用，能够像浏览网页一样愉快。而传统的C/S结构应用程序，要求每一个使用者，必须在自己的计算机上安装一个客户端软件，没有这个软件，就没有办法访问位于服务器上的应用程序。因此C/S结构的笨拙，与广大人民群众日以增长的简单需求之间，产生了深刻的现形矛盾，因此，也就无法适应这个时代的历练，从而，渐渐地退出了程序开发的历史舞台。
应用程序与C/S结构一揖而别，转而投向了B/S的怀抱。应用程序的开发迎来了Web时代。作为Web应用程序领头雁的java，最开始的web应用，是以Applet（小应用程序）的方式出现的。当时的应用形式是，在服务器上发布的小应用程序，当被浏览器访问时，被下载到客户的计算机上运行。这就造成了安全上的隐患。比如，如果Applet（小应用程序）内部包含有数据库的Url，用户名，密码等敏感信息，当Applet被下载到本地以后，随便找个反编译工具，很容易地就能获取到Applet的原代码，甚至比一些垃圾程序员书写的程序更符合编码规范。当此之时，只要不是傻子都能看明白数据库的连接信息。这就等于告诉小偷：“我刚取了50万银子在家里放着呢，家里没有人，门没有锁，我也没有养狗的习惯！”。如果小偷不到你家去做客，那是他人品有问题。
仔细分析Applet的不安全性，我们发现，原因在于Applet是在客户端运行的。基于安全性考虑，人们希望java程序能从客户端走向服务器端。程序在服务器上运行，不被下载到客户端计算机上。此时出现的第一门技术是Servlet，它很好地满足了人们对java安全性的要求。但是接下来的问题是，由于Servlet对所有用于客户端显示的网页代码，都要在服务器端完成，也就是Servlet不但要完成服务器端流程的调度，还要负责页面的实现，而原本简洁的Html一旦在Servlet内部完成，就变得极其繁琐，这给开发过程带来了新的麻烦，严重影响了开发效率，从而影响了Servlet的大面积推广使用。
此后不久，Sun也终于认识到自己有点太CNN了，于是出于简化Servlet应用的目的，推出了新一代Web应用技术规范，这就是JSP规范。JSP通过在html内部嵌入java代码的方式，很好的解决了Servlet对页面显示的实现过于复杂这个难题，让web程序开发进入了一个崭新的时代。然而，倒霉的Sun公司又陷入了新的问题之中。什么问题哪，我们需要好好地思考软件开发过程中的“逻辑问题”。
就个人观点而言，一个web应用程序应该包括三个方面的逻辑，这就是：显示逻辑――负责页面的展现；控制逻辑――负责流程的调度，也就是调用哪个类进行数据处理，数据运算，调用哪个页面，将运算生成的数据显示出来。业务逻辑――这里指的就是复杂繁琐的商业运算和数据处理了。
通过对JSP的分析，我们发现，其Html部分应该负责的是页面显示的内容，属于显示逻辑的范畴，而java脚本，主要负责的是数据运算以及数据处理，应该是属于业务逻辑的范畴。而Jsp没有对这两种逻辑进行很好的划分，从而造成显示逻辑与业务逻辑交织在了一起（这就是所谓的耦合度过高），给程序的测试过程以及后期的维护造成了很大的不便。于是，Sun公司的伟大程序员们，开始伴随着使用者的抱怨和缭绕的烟雾，进行了深刻且细腻的思考。
后来有一天，当一群程序员在苹果树下放松神经的时候，忽然间，来了一阵大风，满树的苹果像冰雹一样砸到了他们的脑袋上，也砸开了他们的视野，新的应用方式诞生了，从此真正开始了java在web应用程序开发过程中的辉煌之旅，并且一直到今天，依然笑傲江湖，环球不败！那么他们思考的是什么哪？
他们发现，针对三种逻辑，JSP的强项在于页面显示，可以用于处理显示逻辑；Servlet的强项是流程调度，可以将JSP中大量用于流程调度的语句提取出来，转而交给Servlet来处理，这样控制逻辑的问题也很好地解决了；那么业务逻辑怎么办哪？JavaBean除了用来封装数据，也可以有方法的啊，为什么不用JavaBean的方法来处理业务逻辑哪，没有理由啊！那就用呗。于是乎，业务逻辑的处理问题，也找到了合适的解决方案（后来，随着编程思想和变成艺术的提高，JavaBean与普通java类之间的关系日渐模糊，人们也更提倡使用没有任何规范的普通java类来处理业务逻辑，并且给他起了个名字，以便更好地提倡这种思想，这就是POJO――普通java类）。于是三种逻辑，各得其所。此后，围绕三种逻辑，在不同复杂程度的业务系统中的应用，产生了两种模式：Model1（JSP＋JavaBean）和Model2（JSP+Servlet＋JavaBean）。Model1比较适合于小规模的系统，比如网站等。而针对复杂的企业级应用（比如金融系统，社保系统等），Sun公司推荐使用Model2。
Model2出现以后，人们于实际应用过程中发现，其中的jsp关注的是页面显示，Servlet关注的是流程控制，而JavaBean关注的是业务处理。这与传统的MVC非常类似，传统的MVC包括了三个方面的内容，模型，视图，控制器。模型：关注数据处理；视图：关注数据显示和报表处理;控制器:负责协调模型和视图。因此，人们开始认为，Model2是基于MVC的。就个人观点而言，如果只是进行网站的开发，还是Model1方便。原因是什么哪？Model2有些复杂。
随着现代社会的发展，商业规则的复杂程度，已经超过了人们的想象。而刁瞒的客户是不管这些的，他们给我们的时间总量是固定的。而软件公司在与客户相处的过程中始终处于弱势地位，是没有太多发言权的，原因很简单，因为公司要盈利，我们要赚客户的钱！
客户限定了时间，也就限定了项目的周期。针对一个复杂的系统，在总量一定的情况下，我们总是在寻求技术时间与业务设计时间的最佳配比。在项目周期固定的情况下，技术时间与业务设计时间是成反比的。两者此消彼长，如果用于技术处理的时间长了，那么业务设计的时间必然就要缩短，同理，如果用于业务处理的时间要增加，就必须缩短技术处理的时间。而在两者的选择过程中，我们不得不选择缩短技术时间，原因很简单，业务规则越来越麻烦，客户并不跟你摆事实，讲道理。而Model2，虽然很好地解决了三种逻辑的划分，可以应用于企业应用程序开发，但是过于繁琐，实现的手法过于粗略。好多基础性的服务没有为我们提供。比如，请求的分发，请求过程中数据的获取等等。于是人们希望应用新的方式替换Model2，或是简化Model2的应用。基于此，大量基于Model2的web框架，如雨后春笋般诞生出来。其中最优秀的就是Struts1和WebWork。后来，两者实现了新的融合，形成了Struts2。由于他们都是基于Model2的，而Model2是基于MVC的，于是人们认为，他们都是基于MVC思想而产生的。
Struts1是第一个成熟的基于MVC的web框架。他的出现使Model2的应用得到了大大的简化，我们将在此后的章节中学习它，并且会发现他的简洁和优美。Struts1简化了Model2的应用，但是只是解决了企业级应用系统的Web层问题。那么企业应用系统还有那些层哪，为什么要有这些层哪，这些层又是用什么方式解决更好哪？
MVC的出现，到今天，已经有40年的历史了，面对复杂的现代商业规则，他已经有些苍老，而用它来解决今天的问题，就好像把秦始皇从地下扣出来，然后给他一个遥控器，说一句：“哥们，把电视机闭了！”。估计这哥们肯定龙颜大怒，回敬你一句：“拖出去，毙了！”。那么既然MVC苍老了，谁还年富力强哪，答案就是分层体系架构！
下面我们来看看贯穿后继章节的分层思想。
一个好的应用系统，一般都是基于分层体系结构来完成的。分层体系结构大致如下图所示：
其中的显示层，对应于MVC的视图（V），控制层对应的是MVC的控制器（C），在后继的章节中，我们将其合并到一起，统称Web层（也有的书上称为展示层）。而Struts只是解决了这里的WEB层的技术实现。其它层又是些什么哪，应用那些技术来实现哪？
随着商业规则复杂度的增加，数据处理也日渐繁琐，而数据库技术的诞生很好地解决了这个问题。可以说，今天的应用程序开发，基本上是离不开数据库的，无论是各种运算，处理，最后都要把数据存储到数据库中，以便于将来查询，或是进一步对数据进行分析和加工。这样程序设计的最终目的，也就转换为对数据库的检索，分析和更新。也就是最终都要把内存中的数据保存到某种数据库中，以便长久存储。这就是所谓的数据持久化。而数据持久层就是解决持久化的一个专用的系统逻辑层。目前来说，应用最为广泛的是Hibernate，他是事实上的数据持久化标准。还有，后继兴起的EJB3技术，也属于此范畴，其前途也是不可限量的。
当持久层技术出现以后，它与原先的模型是什么关系，在模型内部，它处于什么地位，怎么应用持久化技术，这些在原始的MVC中都没有给出明确的定义。这也是MVC思想过时的一个原因，它的模型概念过粗，过于笼统。而分层体系架构，对此作出了明确的定义。持久层，只负责解决数据的持久化（数据持久化对象的增删改查）问题，而为了更好地应用持久层，分层思想引入了业务逻辑层。这一层，一般而言就是普通的java类（POJO），它负责组合多个持久化组件，完成复杂的商业处理（比如利息计算，帐户结转，银行转帐等）。
在一个软件系统中，经常会有一些提供基础服务的类，比如GUID码的生成，MD5加密，四舍五入的处理，电子邮件的发送等等。我们发现他们为具体的业务处理提供了基础性的服务，但是，又不专署于任何一种特定的业务逻辑。为此，分层体系结构将其单独抽象出来，形成了系统服务层。这一层，一般而言，我们也应用普通Java类（POJO）来进行处理。
基于上述分析，我们可以看到，分层体系结构中，一般而言包括四个宏观的逻辑层次，分别是Web层，业务逻辑层，持久层和系统服务层。同时，分层体系结构还定义了它们的强制性调度关系：“同层和相邻层可以相互访问，不允许夸层访问”。比如，控制层，不能跨越业务逻辑层，直接访问持久层。
当分层体系思想出现以后，软件开发系统中的各个组件都有了合适的位置。我们可以高枕无忧地大步前行了。是不是真的这样哪？实践是检验一切的唯一标准，现实的因素决定一切技术和思维的生命周期！
在实际应用过程中，新的问题又出现了。
在完成复杂功能的同时，我们一直在追求着已有功能实现（组件）的复用。而复用的最佳途径是通过已有组件的组合，产生新的功能点。这就不可避免地涉及到组件之间的调用方式问题。传统的组件调用方式，是由应用程序自身管理组件之间的调用和组合，从而造成了组件之间的高耦合，给组件的独立测试和整个系统的后期维护带来了很大麻烦，使软件质量的提高一如镜花水月，无法真正地从技术上实现。同时，在面向对象思想的应用过程中，伟大的程序员们发现，面向对象只是解决了事物之间纵向的一脉相承，而对于诸如系统日志，安全支撑，事务管理等贯穿于整个系统所有功能点的横向公共性功能，没有给出很好的解决方案。为了解决上述问题，一个新的框架应运而生了，它就是Spring。在Spring中，通过DI（依赖注入）思想，很好地解决了组件之间的调度问题。同时，引入AOP（面向切面编程）很好地解决了公共性功能的处理问题。从而给软件开发，带来了一场深刻的，触及灵魂的革命，软件行业，迎来了真正的春天。
在本书的知识体系中，对于分层体系架构的实现，WEB层将采用Struts1.x,持久层将采用Hibernate。而对于整个架构各个组件之间的宏观调度和事务处理，将采用Spring2.x来完成。这就是目前比较流行的SSH整合架构设计。
上述对于数据持久化，分层体系结构，依赖注入等的论述，都只是简单的介绍，目的是让读者能从宏观上对分层体系结构及其SSH实现有个粗浅的了解，在后继的章节中，本书将会进行详细的阐述。不必着急，那样吃不了热豆腐，坚持下去，一切都会好起来。毕竟，人，活着就有希望！
事物都在经历一个从无到有，从弱到强的过程，受实践因素的影响，我们的认识总是停留在一定的局限上的，随着实践的深入，人们的编程思想和编程技术在不断成熟和发展，新的应用技术和方法也会逐步产生，从这个角度来说，浩茫广宇，存在着无数的新思想和新技术等待我们去发现和实现。而程序员的乐趣也正在于此：可以不断地接触新奇的世界，新奇的思想。胸含广宇，气象万千！
最后，演绎林锐先生的一段话，作为本篇的结束：
让我们高举JAVA主义、软件工程思想的伟大旗帜，紧密团结在以Sun公司为核心的软件巨头周围，沿着比尔·盖茨先生的生财之道，不分白天黑夜地吐血编程，把建设有中国特色软件产业的伟大事业，全面推向21世纪。构建和谐社会，享受大康人生！
majianan 2009-06-14
- 打赏
- 举报
up
加载更多回复（200）
