手机浏览 RSS 2.0 订阅 膘叔的简单人生 , 腾讯云RDS购买 | 超便宜的Vultr , 注册 | 登陆
浏览模式: 标准 | 列表2008年08月15日的文章

PHP+MYSQL的OA为何没有Java的值钱

Submitted by gouki on 2008, August 15, 11:54 PM

本文来自于天极网。意见不敢苟同，COPY过来也是想听听大家的意见。
原文如下：

为什么PHP+MYSQL的OA不如JAVA写的值钱？？？
  1. 现在市场上的oa基本上可归结为两大阵营，即php阵营和java阵营。但对接触oa不久的用户来说，看到的往往只是它们的表相，只是明显的价格差异，却很难看出它们之间的实际差异。其实， PHP + MYSQL 不值钱不仅仅局限于oa软件，而是整体上PHP + MYSQL开发的软件都不如java开发的软件值钱。为什么PHP + MYSQL 的OA为什么不值钱呢？首先得明白php和java之间的差异才行。  
  2.   
  3. 　　1、系统的技术架构比较  
  4.   
  5. 　　分层是将系统进行有效组织的方式，分而治之的思想是计算机领域中非常重要的思想。在好的分层思想引导下，便能实现“高内聚、低耦合”，也能将具体的问题割裂开来，易于控制、易于延展，更易于分配资源。PHP只能实现简单的分布式两层或三层的架构，而JAVA在这方面就十分强大，可以实现多层的网络架构。运用MVC的设计模式，可使oa系统具有更加高效、合理的系统架构。技术架构的落后，使运用php编写的oa软件系统先天不足，而后天又无法补足其先天上的劣势。使得系统在可拓展性、需求应变性上与JAVA编写的oa软件系统的差距越来越大。架构的差距，注定了php做的oa充其量是个小家碧玉，始终无法和java这种大家闺秀同台竞技。  
  6.   
  7. 　　2、数据库访问比较  
  8.   
  9. 　　PHP可编译成具有与许多数据库相连接的函数。将自己编写外围的函数去间接存取数据库。通过这样的途径当更换使用的数据库时，可以轻松地修改编码以适应这样的变化。但PHP提供的数据库接口支持彼此不统一，比如对Oracle, MySQL，Sybase的接口，彼此都不一样。由于PHP对于不同的数据库采用不同的数据库访问接口，所以数据库访问代码的通用性不强。  
  10.   
  11. 　　而Java通过JDBC来访问数据库，通过不同的数据库厂商提供的数据库驱动方便地访问数据库，访问数据库的接口比较统一。如果同样是将开发的web应用从MYSQL数据数转到ORACLE数据，PHP需要做大量的修改工作，而且比较繁琐。但JAVA开发的便只需要很少的更改便能实现。  
  12.   
  13. 　　数据库访问方式的差异，奠定了php开发出的oa和java开发出来的oa是马车和火车的差距，前者只能亦步亦趋而且额度有限，后者却是工业化的结晶，不仅能够包容万物而且速度上稳步提升。  
  14.   
  15. 　　3、安全性对比  
  16.   
  17. 　　在同是开源和跨平台的java面前，php丢掉了很多的优势。在代码的安全性上尤为突出。php的开发程序在别人拿到代码后，可以很容易的进行修改。而 java开发的程序由于无法看到完整的源代码，只能看到一些编译好的类文件，所以安全性较高。加之系统架构的优势，在安全性上php和java是相去甚远。  
  18.   
  19. 　　如果非要将php和java在安全性上做个比较的话，同一个小偷光顾php那是随便拿来随便改，想拿什么拿什么，拿的高兴还能大笔一辉某某到此一游。而光顾java的时候，便会发现警察把守，内设自动报警装置，即便突破重重阻扰后进入居室。那值钱的东西都放在加密后的保险柜中，只能望洋兴叹、铩羽而归。  
  20.   
  21. 　　4、前瞻性和拓展性  
  22.   
  23. 　　从整体来说，php适用于中小型系统，而java适用于大型系统。Php能够将单一的事件做好，但却不适合完成集成度较高的多项并发事件。为什么说php适合中小型系统而不适合做大系统呢？  
  24.   
  25. 　　首先， php缺乏多层结构支持。而对于大型的系统负荷站点，只能采用分布计算。将数据库、应用逻辑层和表示逻辑层彼此分开，并将同层的根据流量分开，组成二维数组。而php恰恰缺乏这种支持。  
  26.   
  27. 　　其次，PHP提供的数据库接口不统一，要将多个不同的数据库数据统一需要花费很大的力气。而JAVA则没有这种缺陷，可通过SUN Java的Java Class和EJB获得规模支持，通过EJB/CORBA以及众多厂商的Application Server获得结构支持。如IBM的E－business，它的核心是采用JSP/Servlet的Web Sphere，是通过CGI来提供支持的。  
  28.   
  29. 　　如果将Php比作将才，具备独挡一方的能力。那么java便是帅才，具有较好的前瞻性和拓展性，整体布局和协同能力强。能够指挥千军万马，最后逐鹿中原。  
  30.   
  31. 　　5、开发成本比较  
  32.   
  33. 　　既然php在诸多方面都不如java优异，那么php开发出的oa产品何以与java产品竞争呢？在于Php阵营普遍走的是低端路线，而java阵营走的是中高端路线。两者之间交叉的区域较小。  
  34.   
  35. 　　软件价格的高低很大程度上和自身成本和功能相挂钩。php的入门门槛较低，绝大多数学过c的程序员都很容易转型为php程序员，这使得php程序员的泛滥成灾的同时，低成本的php软件产品也层出不穷。以PHP最经典的组合PHP + MySQL + Apache为例，由于所有软件都是开源免费的，所以投入并不高。  
  36.   
  37. 　　而java开发需要特定的环境，成长为一个合格的java程序员需要一定的时间，java程序员的成本也是php成本的几倍。Java的web应用服务器免费的有Tomcat、JBoss等，而要想具有很好的商业化服务便必须选用Web Sphere和 Web logic。这其中投入的成本无形中便超是php成本的N倍。所以，java开发oa的成本要远远高于php开发出来的同类软件产品。但也正由于java 开发的成本较高，很难实现抄袭和短期内逾越的可能，也使得java用开发出的产品门槛更高。  
  38.   
  39. 　　不怕不识货，就怕货比货。Php开发出来的产品也能用，但是和java开出的同类产品是没法比较的。正因为php开发的产品整体性能和java开发的相去甚远，所以php运用低成本的低价优势和同类的java产品抗争，以价格落差来平衡购买者的心态。所以，PHP + MYSQL 的OA不值钱也就不足为怪了。  

在作者眼里，PHP好象就只能处于低层次的开发。其实开发这东西也是双面性的，你让一个新手写JAVA和让我一个老手写PHP，写出来的东西你认为哪个值钱？
之所以JAVA比PHP值钱，归根结底还是观念，大多数人认为JAVA是科班出身，而PHP则是扎根草堆，虽然最近两年也开始逐步有培训班的出现，但和JAVA比起来就差远了。
就象大腕里说的：你要用PHP写的OA，你都不好意思提出口，怎么着也得是JAVA，.NET之类的吧。

Tags: oa, 价值, java

Misc | 评论:0 | 阅读:20206

REST与SOAP之比较——SOAP篇

Submitted by gouki on 2008, August 15, 11:41 PM

比较REST和SOAP的“风格”

REST依赖一套简单的“动词”，把所有的复杂性都转移到了指定资源的“名词”中。与此不同，SOAP却有一套相当复杂的XML格式化命令和数据传输选项。

在Web服务发展的初期，XML格式化消息的第一个主要用途是，应用于XML-RPC协议，其中RPC代表远程过程调用。在XML远程过程调用(XML-RPC)中，客户端发送一条特定消息，该消息中必须包括名称、运行服务的程序以及输入参数。相反， REST风格的请求却不关心正在运行的程序是什么，它仅仅请求命名资源。

XML-RPC只能使用有限的数据类型种类和一些简单的数据结构。人们认为这个协议还不够强大，于是就出现了SOAP——其最初的定义是简单对象访问协议。之后，大家逐渐意识到SOAP其实并不简单，而且也不需要必须使用面向对象语言，所以，现在人们只是沿用SOAP这个名称而已。

XML-RPC只有简单的数据类型集，取而代之，SOAP是通过利用XML Schema的不断发展来定义数据类型的。同时，SOAP也能够利用XML 命名空间，这是XML-RPC所不需要的。如此一来，SOAP消息的开头部分就可以是任何类型的XML命名空间声明，其代价是在系统之间增加了更多的复杂性和不兼容性。

另外，非常重要一点是，REST是需要请求HTTP的，与其相比，SOAP更具优势，SOAP消息可以由所有能够处理Unicode文本的传输方式来传送，很可惜，这一点通常不被人们所认可。事实是，由于HTTP穿透防火墙的便捷性，以及开发商们对Web非常熟悉，因此，人们还在继续强调着HTTP传输。

随着计算机行业的觉醒，人们发现了基于XML的Web服务的商业潜力，于是，各家公司开始不断地发掘想法、观点、论据以及标准化尝试。W3C曾经设法以“Web服务活动”的名义来组织成果展，其中也包括实际做出SOAP的XML协议工作组(XML Protocol Working Group)。与Web服务有关的标准化成果——从某种程度上说与SOAP相关或者依赖于SOAP——的数量已经倍增了到了令人惊讶的程度。

最初，SOAP是作为XML-RPC的扩展而发展起来的，它主要强调的是，通过从WSDL文件中所获得的方法和变量名来进行远程过程调用。现在，通过不断进步，人们发现了更多的使用SOAP的方式，而不仅仅是采用“文件”方式——基本上是使用一个SOAP信封来传送XML格式化文件。无论如何，要掌握SOAP，了解WSDL所扮演的角色是最根本的。

Web服务描述语言或WSDL
为了创建一个用于描述Web服务的XML格式化文件，Web服务描述语言(WSDL)标准提供了足够多的细节，以便能够构建出客户端代码，从而访问服务或者服务器端代码以提供服务。一个服务的WSDL文件将会为你提供以下几个方面的内容：

用于访问服务的地址信息
用于传送信息的传输协议(例如，通道数)
用于所有可使用功能的名称和接口使用方法
在所有的请求和响应中所使用的数据类型
2001年3月，W3C推出了WSDL 1.1版本用于讨论，这并不是最终确定的规范。W3C Web服务描述工作组目前正在开发该规范的2.0版本，基本上已经到了尾声。虽然，WSDL通常是用于特定的SOAP服务，但是，从理论说，它是完全可以用于特定的REST风格的GET或者POST操作的。

能够根据服务的WSDL描述来自动创建客户端和服务器端代码，支持这一功能的开发环境目前使用得很广泛，以便能够适用于Web服务器和Web服务客户端的不同程序设计语言。如果你使用Google搜索“SOAP IDE”的话，大概会出现上百万条相关信息。也有这样的工具，根据Java或C#对象来生成相应的WSDL和代码。自动生成代码也许能够使你的开发效率更高，但是离优化却是越来越远。

安全与SOAP

如果企业使用SOAP来传送有价值的信息的话，那么，安全就是最重要的问题。由OASIS组织发起，计算机行业的领导者们已经联合开发了一套标准，称为WS-Security。这个标准对基本的SOAP通信做出了改善，以便能够处理以下几个问题：

消息机密性——由于拦截HTTP消息的方式非常多，因此，在请求和响应过程中，必须能够对所有重要信息加密。很幸运，现在的加密技术非常先进，我们能够对消息内容进行加密，以保证消息不被修改。

客户和服务身份——必须能够核实SOAP请求来源的身份。

结论

在开发人员的意识里，对于Web服务的开发而言，REST和SOAP风格各有千秋。SOAP拥有更为详尽的标准化成果和开源工具。除此之外，现在，有许多集成开发环境能够在现有代码的基础上，依据接口方法自动生成SOAP。如果你需要使用WSDL来发布你的服务，或者你需要一些安全功能如消息签名和加密，那么，SOAP能够确保消息的安全性。另一方面，如果你希望使用简单接口来公布一些信息，而不需要繁琐的处理过程，那么，REST也许是最佳选择。

——END——
原文来自：http://www.diybl.com/course/3_program/java/javajs/2007918/71772.html
仅作参考

Tags: rest, soap, compare, 比较

PHP | 评论:0 | 阅读:26326

REST与SOAP的比较——REST篇

Submitted by gouki on 2008, August 15, 11:40 PM

　我有这样一个推断，在计算机世界中，但凡那些让开发人员记住的重要概念，都有一个很酷的名称首字母缩写，否则的话，开发人员很快就会将其抛之脑后。比如Ajax、SOAP以及REST就证明了这一点。

REST能够在计算机领域被广泛采用，它走的道路是不同寻常的。这个术语是由Roy Fielding创造的。Fielding毕业于Irvine市加利福尼亚大学，在他的博士学位论文中第一次提出了REST这个概念。在Web方面，我们必须承认Fielding是非常精通的，他曾经帮助创建HTTP 1.0规范，该规范从1996年开始就为Web提供基本准则。他在Web标准方面非常有经验，这为他的这篇博士论文奠定了坚实的基础。

Fielding指出，使用且符合代表性状态传输(REST)设计约束的 Web 上部署的组件，可以充分利用 Web 的有用特性，万维网(World Wide Web)才能够达到最佳的工作效果。可以这样理解REST——当一个浏览器得到并且显示构成HTML页面的各个元素时，它正在获取资源的当前状态的表现形式。在Fielding的博士论文中，他列举了REST风格的设计约束，并且解释了为什么这些约束能够充分利用Web 的有用特性，使其达到最佳状态，以及这些约束的关键所在。同时，在论文中，他也包含了一些关于REST和某些目前的Web风格之间 “不符合”的讨论，以及这些Web风格是如何导致设计无法利用Web特性的。

Fielding认为，对于使用HTTP承载应用程序协议穿越防火墙，XML-RPC 和SOAP所采用的方式是“从根本上被误导的概念。”它们所采用的方式违背了设立防火墙的概念，结果是，防火墙厂商为了保护系统需要侦察出所承载的协议。由于大多数SOAP应用程序使用HTTP都是为了穿越防火墙，因此，你可以发现REST与SOAP之间的冲突是从哪里开始的。Fielding认为，如果你打算使用HTTP的话，就应该与充分利用HTTP本身的含义。

REST风格强调，通过有限的操作或者是“动词”以及一个组件之间的标准接口，也就是HTTP协议提供的借口，来提升客户与服务之间的交互。通过为每一个资源分配其自己的URL，来实现灵活性，REST可以调用包含上百个URI的资源类型的客户，其中的关键是REST能够给你无限多的“名词”。REST使用HTTP的动词——简单的良定义操作集:POST, GET, PUT,DELETE进行请求和响应，从而避免了歧义。举个例子，GET只能够简单地返回资源的表现形式，而不能够创建任何其他的内容。

在Web发展的初期，由于人们都在试验通过收集各种不同来源的元素，从而把Web应用程序融合在一起，有大量这种Web服务的不成熟探索的例子——从HTTP页面中解析信息，用于页面创建者没有计划到的用途。这种“屏幕抓取”的Web类比表明，REST风格的方法是先于那些更加复杂的Web服务而出现的。

REST是一种风格而不是一个标准

你可能会把软件的架构风格当作对上层设计模式的抽象。然而，根据Fielding所说，设计模式的堆砌并不等同于架构风格，因为模式是非常接近于特定问题的。

由于REST是超文本系统的一种风格，而不是Web服务的，因此，本文的标题“REST与SOAP之比较”就有些让人误解。然而，很多软件设计人员会将其混淆，他们在考虑如何创建Web服务时，会得出这样的结论：SOAP过于复杂，而简单的类似于REST的设计却更加适合。

REST与RPC风格之比较

远程过程调用的架构，是应用在基于XML-RPC或者 RPC风格的SOAP的Web服务中的，它却有着完全不同的风格。客户端发出命令，以使服务做出特定的操作。换句话说，RPC有动词的倾向。

REST强调资源(名词)有统一的接口以此来对它们寻址，而RPC强调过程(动词)有统一的接口来激发它们。一个基于RPC的架构，动词数量是没有限制的。REST说，我们使用四个动词——非常熟悉，HTTP标准的GET、POST、PUT以及DELETE——来进行请求和响应，REST使用资源寻址来处理其可变性。

一个简单的REST举例

假设我们希望一个Web服务暴露一部分目录，从这个目录中，用户将能够得到一些描述、图片、安装指令等等。为了得到数字“n1996-01”的描述，用户需要格式化一个GET请求，类似于下面的这个URL：

http://company.com/catalog/description/n1996-01

在处理这个请求时，“/catalog”将映射到一个服务中，之后，通过该服务对“description/n1996-01”进行解释，从而定位资源。在创建响应时，服务需要使用内容类型(Content-Type)的头文件来指定返回格式。在这种情况下，假定返回格式是HTML或者XML，客户端能够使用它来控制页面的布局。如果要得到图片，那么这个请求将对“/catalog/picture/n1996-01”进行寻址，返回的响应将是图片内容类型(Content-Type)。

REST的商业应用

最近几年，大多数Web商业企业开始对REST非常感兴趣。Google Data API(目前还在测试版本)专门使用REST规则来提供简单的协议。对服务的HTTP GET请求的响应结果是，采用Atom或者是RSS联合格式的XML数据。Google也使用Atom以及POST、PUT和DELETE操作来完成公共协议。eBay服务提供通过使用不同语言工具来访问服务，这些工具包括文档/文字风格的SOAP以及REST风格。

那么，对于XML-RPC和SOAP所具有的RPC风格而言，REST风格是否是一个具有竞争力的替代者呢?当然，我决不这样认为，在下一篇文章中，我将尽量向大家展现SOAP所向无敌的领域。
———END——
原文来自：http://www.diybl.com/course/3_program/java/javajs/2007918/71777.html
仅作参考

Tags: rest, soap, compare, 比较

PHP | 评论:0 | 阅读:27426

javascript---浅析注册事件

Submitted by gouki on 2008, August 15, 11:18 PM

在这个浮躁的世界里，说实话，很难看到一两篇好的文章，我写的一般都比较垃圾，但我会尽量发现精品。在闲逛的时候发现这篇文章确实不错，虽然讲的比较简单一点。

文章是从cssrain.cn上COPY而来，原文网址为：http://item.feedsky.com/~feedsky/cssrain/~6110346/103912558/4218245/1/item.html

内容如下：

首先是最常规的方法：

XML/HTML代码
  1. <p id="para" title="cssrain demo!" onclick="test()" >test</p>  
  2. <script>  
  3. function test(){  
  4.   alert("test");  
  5. }  
  6. </script>  

当某一天，我们知道JavaScript要跟HTML结构实现分离后，就会改了一种写法:

XML/HTML代码
  1. <p id="para" title="cssrain demo!">test</p>  
  2. <script>  
  3. function test(){  
  4.   alert("test");  
  5. }  
  6. window.onload = function(){  
  7.     document.getElementById("para").onclick = test;  
  8. }  
  9. </script>  

当我们工作越来越久后，有时候我们需要对某个元素绑定多个相同的事件类型：

XML/HTML代码
  1. <p id="para" title="cssrain demo!">test</p>  
  2. <script>  
  3. function test(){  
  4.   alert("test");  
  5. }  
  6.   
  7. function pig(){  
  8.   alert("pig");  
  9. }  
  10.   
  11. window.onload = function(){  
  12.      document.getElementById("para").attachEvent("onclick",test);  
  13.      document.getElementById("para").attachEvent("onclick",pig);  
  14. }  
  15. </script>  

在一段时间内，你并没发现这段代码有任何错误。
某一天，一个名叫firefox的浏览器 闯入你的视野，当我们把这段代码放到firefox中执行后，
发现并不能正常运行。 问题就这样，越来越多，然而作为一名JS程序员，这些都是必须面对的。

为了解决这段代码的平台兼容性问题，我翻翻手册，知道了firefox跟ie的区别：
firefox中注册事件使用：addEventListener方法，同时为了兼容ie，我们必须用到if ... else...

XML/HTML代码
  1. <p id="para" title="cssrain demo!">test</p>  
  2. <script>  
  3. function test(){  
  4.   alert("test");  
  5. }  
  6.   
  7. function pig(){  
  8.   alert("pig");  
  9. }  
  10.   
  11. window.onload = function(){  
  12.          var element =  document.getElementById("para");  
  13.          if(element.addEventListener){  // firefox  , w3c  
  14.                 element.addEventListener("click",test,false);  
  15.     element.addEventListener("click",pig,false);  
  16.          } else {   // ie  
  17.     element.attachEvent("onclick",test);  
  18.     element.attachEvent("onclick",pig);  
  19.          }  
  20. }  
  21. </script>  

此时，代码就可以在多个平台上工作了。

但随着水平的进步，你不满足每次都去判断，你想把这个判断封装起来，以后可以直接调用：

XML/HTML代码
  1. <p id="para" title="cssrain demo!">test</p>  
  2. <script>  
  3. function test(){  
  4.   alert("test");  
  5. }  
  6.   
  7. function pig(){  
  8.   alert("pig");  
  9. }  
  10.   
  11. function addListener(element,e,fn){  
  12.      if(element.addEventListener){  
  13.           element.addEventListener(e,fn,false);  
  14.      } else {  
  15.           element.attachEvent("on" + e,fn);  
  16.      }  
  17. }  
  18.   
  19. window.onload = function(){  
  20.          var element =  document.getElementById("para");  
  21.          addListener(element,"click",test);  
  22.          addListener(element,"click",pig);  
  23. }  
  24. </script>  
XML/HTML代码
  1. <p id="para" title="cssrain demo!">test</p>  
  2. <script>  
  3. function test(){  
  4.   alert("test");  
  5. }  
  6.   
  7. function pig(){  
  8.   alert("pig");  
  9. }  
  10.   
  11. function addListener(element,e,fn){  
  12.      if(element.addEventListener){  
  13.           element.addEventListener(e,fn,false);  
  14.      } else {  
  15.           element.attachEvent("on" + e,fn);  
  16.      }  
  17. }  
  18.   
  19. window.onload = function(){  
  20.          var element =  document.getElementById("para");  
  21.          addListener(element,"click",test);  
  22.          addListener(element,"click",pig);  
  23. }  
  24. </script>  

 至此，作为一个程序员的工作就完了。
中间我们从一个最传统，最基本的写法 ， 然后实现Js和HTML的分离，然后又实现对同一个元素注册多个事件，期间，我们发现注册事件的兼容性问题。最后我们对注册事件的方法进行封装，方便以后使用。

———END——

浏览器这东西还是非常害人的。啥时候才能有统一的标准 ？？？

Tags: javascript, 注册

Javascript | 评论:0 | 阅读:21759