|
这个主题共有 29 回复 ／ 2 页 [
1 2
下一页
]
|
|
|
|
|
|
两年的技术经历，在J2EE上疑惑
|
发表: 2006年11月29日 16:53
|
回复
|
|
本人工作三年，做了两年的技术和一年的需求分析，停止了一年的技术探索后，再回头来去了解，却发现两年的技术经历是如此的不扎实，我问自己几个最常用的概念，但我却疑惑了：
1.我们谈论了J2EE，但究竟什么是J2EE？它是规范吗？它是技术吗？它是在什么样的背景下出现的，为了解决什么？
2.我们也谈架构？但究竟什么是架构？架构出于什么目的？架构的目标是什么呢？
3.我们频繁的使用Struts,但它帮我们解决什么呢？可能有人会说它是MVC的实现，但这不是问题的答案.MVC它又解决了什么呢？
望各位能够指点一二
|
|
|
|
|
|
Re: 两年的技术经历，在J2EE上疑惑
|
发表: 2006年11月30日 16:10
|
回复
|
|
1. J2EE是规范，是一种JSR标准，有详细文档，阐述J2EE提供哪些功能，可以下载这样文档，当然还有一些代码接口，这是典型Java世界中的框架代码+标准文档形式，这是只有自由世界才有的规范，在微软MS世界你是绝对不会看到的，所以，从微软转过来的，会晕，会不适应，不能再按照他们以前的经验来看待自由的新世界。
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论坛也可以看到大家这方面讨论。
说太多，有感而发，个人意见，仅供参考。
|
|
|
|
|
|
Re: 两年的技术经历，在J2EE上疑惑
|
发表: 2006年12月03日 15:29
|
回复
|
|
"架构就是要有预见性，特别是Java世界，技术流派众多，优劣共存，让人吃药的技术比比皆是，不象微软世界，有微软这个专制强权的架构设计者和提供者告诉你用什么，除此之外别无选择，在Java自由世界，你可能不小心走上一个不归路，软件架构一旦错误，就象出发的方向发生问题，南辕北辙成语就是说这个意思，花再多精力再多钱，再强的人都没有用，项目照样失败。
所以，在Java世界选择技术，就象女孩子到自由市场淘货，必须冒被骗失败的风险，但是其中乐趣也是不言而喻的，你会成为技术专家，当然，如果你想很多找到合适的架构设计，那么借助外力，象J道都提供这样架构设计服务，可以在短时间介绍一些这个自由市场哪些东西是性价比好，值得买，找个有信誉的内行当地人做咨询，就是这个道理。"
-------彭老大这番话说到点子上了,学Java可以成为技术专家,学.Net可以成为赚钱专家:)
|
|
|
|
|
|
Re: 两年的技术经历，在J2EE上疑惑
|
发表: 2006年12月04日 19:40
|
回复
|
|
Banq大哥，（或许应该叫叔叔吧^^）您好！
我是一名国家示范软件学院的在校大学生。经过两年多的大学学习，始终没有掌握到软件设计和开发的精髓，甚至一度想放弃，直至我接触到了Java。昨天，我无意中发现了Jdon这个网站，立刻被他所吸引，相见恨晚。您提出的许多见解都是我一直以来所追寻的，这些软件架构的设计、oo思想的追求，令我赞叹不已。同时我也很钦佩您如此高超的洞察力和判断力，身在校园之外这么多年就能把国内软件教育的病根洞察得一清二楚。在学院刚开Java的课程时，大部分学生都乐于接受，表现出了很深的兴趣，那还只是在J2SE的阶段，因为长时间的C++学习已经使得他们非常厌烦。可是，一旦到了J2EE阶段，就连基本的JSP、Servelet、MVC这些都得到了大部分人的排斥。学院允许选择.Net和Java，结果很多人投到了MS的阵营里面去开发asp.net的东西了，更不用说后来的EJB、hibernate。我看到您的一句话感受太深：“这是只有自由世界才有的规范，在微软MS世界你是绝对不会看到的，所以，从微软转过来的，会晕，会不适应，不能再按照他们以前的经验来看待自由的新世界。”
我钦佩您，追寻您的思想，更想去学习您。您放心好了，中国的软件教育是失败的，可是还有很多不愿放弃的年轻人，他们有开放的思想，为这个事业而奋斗。
|
|
|
|
|
|
Re: 两年的技术经历，在J2EE上疑惑
|
发表: 2006年12月11日 13:52
|
回复
|
|
|
OO面前大家都在一个起跑线上,谢谢老大给我们指明方向
|
|
|
|
|
|
Re: 两年的技术经历，在J2EE上疑惑
|
发表: 2006年12月12日 13:57
|
回复
|
|
<b>J2EE 是什么？</b>
在说明J2EE是什么之前，先描述一下它出现的背景：
1.企业应用系统复杂度越来越高，系统往往是构建已有系统之上的新应用，已有系统往往呈现多样性，而且要求新应用能够不断的扩展来满足业务的变化。在性能和安全性方面要求也到了空前的地步。
2.随着企业应用的复杂度和要求的提高，应用开发商的成本和响应时间成级数上升。
3.许多公司开发了自己的中间件以降低称本，缩短响应时间，但是各个公司的不同的中间件不能组装在一起形成服务。
在这样的背景下，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规范专心开发业务构件，然后部署到中间件中形成应用。
|
|
|
|
|
|
Re: 两年的技术经历，在J2EE上疑惑
|
发表: 2006年12月12日 14:01
|
回复
|
|
<b>BANQ:<b>
不知道我这样理解J2EE是否有不合理的地方，请指点一二
关于架构和sturts 下次有时间再向您讨教
|
|
|
|
|
|
Re: 两年的技术经历，在J2EE上疑惑
|
发表: 2006年12月13日 09:43
|
回复
|
|
你的背景描述是正确的，我想进一步指出的是，要了解为什么有如此强调背景，肯定有针对性的。
针对什么呢？原来很早以前大家都是用VB/Delphi或C++来做企业开发，因此，很多因素都重视不够，比如VB/Deplphi系统的并发性等等，这些系统在一个小局域网内还可以，但是这样的系统不能经受大的并发访问。
我曾经听HP公司一个loadRunner专家说，中国工商银行的大部分系统经过并发loadrunner测试，都要降级（也就是不能面对全国性的访问）。
当然性能是一个方面，更方便的组件中间件支持更重要，不需要很多东西自己动手开发，拿来主义。
目前，J2EE进入JavaEE时代，也就是返璞归真，J2EE其实就是Java系统，这样，很多Java模式就可以在J2EE中应用，但是当初，J2EE为了追求强大的功能，忽略了OO设计，导致产生专门的J2EE模式，而且模式这个词语被用来作为修饰软件缺陷的幌子。现在到了J2EE5.0也就是改名为JavaEE5.0后，一切都比较恰当了，强大功能和良好的OO都得到体现。
JavaEE标准文档规定了很多功能，我们有时只需要少部分功能，全部掌握需要时间，Spring这样开源源码虽然只遵循J2EE中Web部分，它也提供了JavaEE中其他功能的另外一种实现，所以，为什么有时说Spring也复杂，他也是一本J2EE/JavaEE完整教科书。
不管是标准还是其他实现，关键从宏观掌握，然后从自己的观点，根据实际情况来判断取舍，这样，才是架构的真正要旨。
|
|
|
|
|
|
Re: 两年的技术经历，在J2EE上疑惑
|
发表: 2006年12月13日 09:45
|
回复
|
|
|
|
|
|
|
|
Re: 两年的技术经历，在J2EE上疑惑
|
发表: 2006年12月13日 11:21
|
回复
|
|
banq:
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
当然性能是一个方面，更方便的组件中间件支持更重要，不需要很多东西自己动手开发，拿来主义
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
这部分内容我非常的认可，JavaEE 能够解决性能问题，它也使得很多复杂的东西由中间件实现了，具体的应用只要关心业务。
但是对于下面的论述我感到有些疑惑，不能够理解其意：
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
目前，J2EE进入JavaEE时代，也就是返璞归真，J2EE其实就是Java系统，这样，很多Java模式就可以在J2EE中应用，但是当初，J2EE为了追求强大的功能，忽略了OO设计，导致产生专门的J2EE模式，而且模式这个词语被用来作为修饰软件缺陷的幌子。现在到了J2EE5.0也就是改名为JavaEE5.0后，一切都比较恰当了，强大功能和良好的OO都得到体现。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
具体的疑问如下：
1.不管是命名为J2EE还是Java EE,都是Java解决方案，用该解决方案构件的系统都是java系统，那么java模式不管是在以前还是现在都是可以运用的，“为什么会在以前不能运用呢？（能够赐一个实例，让我能够理解）”
2.为什么说J2EE 忽略了OO，它会和OO产生矛盾吗？
3.对于模式，同样存在2中的疑问：它为何会和模式有矛盾？
4.我不知道SUN改名的目的，但是它的名字无论怎么改，它仍然是JAVA解决方案，为何会在OO上产生了效果？Java EE 5 只是添加了新的技术用于更方便的解决一些问题
|
|
|
|
|
|
Re: 两年的技术经历，在J2EE上疑惑
|
发表: 2006年12月13日 13:55
|
回复
|
|
>为什么会在以前不能运用呢
不能说完全不能运用，但是，总是让人感觉J2EE和Java有些区别，其实应该是一样得，J2EE专门有一套J2EE核心模式，这些模式只能让J2EE更复杂，而且有一些与GoF设计模式有矛盾之处。实际上，我认为不应该存在专门的J2EE核心模式，所以，尽管SUN的J2EE核心模式出现很久，但是我并没有将其在Jdon网站展开讲解，还是坚持GoF设计模式。
>为什么说J2EE 忽略了OO，它会和OO产生矛盾吗？
J2EE实际是面向组件，或者认为是面向构件，在构件这里OO和工业界开始有分歧，工业界SUN他们将构件导引到SOA，SOA和OO虽然目的都是一致，都是为解决随时变化且复杂的需求，但是方式不一样，OO主要看重开发方式，而SOA看重，买构件厂商的服务，用他们的构件搭配你的应用。
所以，有时工业界J2EE会和OO有些不一致的地方。
另外，以前EJB2时，很容易导致初学者过程化编程，当然，我是坚持模型驱动开发，使用EJB2也是这样，但是注重设计人太少，功利主义占据上方，所以，最后非OO罪责落在EJB2上，Spring正是借助这个EJB2的软肋而发展起来的。
>对于模式，同样存在2中的疑问：它为何会和模式有矛盾？
模式是实现OO手段之一，目的是为软件松耦合；但是有的模式不是为这个目的，而是为弥补其框架设计问题的，如J2EE核心模式中业务代理模式，如果EJB是POJO的话，就无需在EJB前面再套一个普通JavaBean来解耦客户端和EJB了；又比如：Hibernate3中的Open Session In View，需要将Hibernate的数据操作Session在一个request产生开始之初就打开，实际就是持久层的功能需要在表现层完成；这些模式都是为掩盖其本身弱点和不足。
>我不知道SUN改名的目的
J2EE中有一个2，表示构建于当初Java 2这样语言，其实J2EE与JavaEE比，当然后者更好一些，表示JavaEE还是Java，J2EE就有些让人感觉不同，最后，一些人会真走得很远....
|
|
|
|
|
|
Re: 两年的技术经历，在J2EE上疑惑
|
发表: 2006年12月15日 14:24
|
回复
|
|
|
俺以为，在好的技术也要为应用服务。foxpro的成本肯定小于java的，同样，用低一些的成本就可以解决，为什么还要用一堆复杂的技术呢。那都是商人的道理
|
|
|
|
|
|
re:两年的技术经历，在J2EE上疑惑
|
发表: 2007年03月01日 13:50
|
回复
|
|
|
|
|
|
|
|
re:两年的技术经历，在J2EE上疑惑
|
发表: 2007年04月09日 15:37
|
回复
|
|
|
呵呵！总归一个答案：就是解决拉商业的需要，不管什么技术都是在商业的基础建力起来的，只有顺应拉商业的需求才能保存下来。
|
|
|
|
|
|
re:两年的技术经历，在J2EE上疑惑
|
发表: 2007年04月14日 18:19
|
回复
|
|
语言只是一个工具，每种语言都有其优点
换个角度看看每个语言的优点，收获则会更大
我们往往用以往的经验来判断问题，因为好坏都是以往的标准
|
|
|
|
|
|
这个主题有 29 回复 ／ 2 页 [
1 2
下一页
]
|
|
|
注册
登陆
上一主题
下一主题
