|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
认真的记,感觉很紧张根本就没有时间和能力,来对技术知识点进行思考。这样课下就只能对知识进行简单的理解,其实简单的理解就是记忆课堂上讲的知识点,最好理论
1、一直利用MVC框架。
2、在每层都使用主动单位测试和测试办理。
3、依照标准来举行开辟,而不是依照使用服务器来举行开辟。
4、从一入手下手就企图利用J2EE平安性。
5、创立您所晓得的。
6、当利用EJB组件时,一直利用会话Facades。
7、利用无形态会话bean,而不是有形态会话bean.
8、利用容器办理的事件。
9、将JSP作为暗示层的首选。
10、当利用HttpSession时,只管只将以后事件所必要的形态保留个中,其他内容不要保留在HttpSession中。
11、在WebSphere中,启动静态缓存,并利用WebSphereservlet缓存机制。
12、为了进步程序员的事情效力,将CMP实体bean作为O/R映照的首选办理计划。
1.一直利用MVC框架。
MVC框架能够将营业逻辑(Javabeans和EJB组件)、把持器逻辑(Servlets/Struts举措)、暗示层(JSP、XML/XSLT)明晰地分别开来。优秀的分层能够带来很多优点。
MVC框架关于乐成利用J2EE是云云主要,乃至没有其他最好理论能够与其等量齐观。模子-视图-把持器(MVC)是计划J2EE使用程序的基本。MVC将您的程序代码复杂地分别上面几个部分:
卖力营业逻辑的代码(即模子——一般利用EJB大概一般的Java对象来完成)。
卖力用户界面显现的代码(即视图——一般经由过程JSP及标志库来完成,偶然也利用XML和XSLT来完成)。
卖力使用程序流程的代码(即把持器——一般利用JavaServlet或像Struts把持器如许的类来完成)。
假如您不遵守基础的MVC框架,在开辟过程当中就会呈现很多的成绩。最多见的成绩就是在视图部分增加了太多的成份,比方,大概存在利用JSP标志来实行数据库会见,大概在JSP中举行使用程序的流程把持,这在小范围的使用程序中是对照罕见的,可是,跟着前期的开辟,如许做将会带来成绩,由于JSP慢慢变得愈来愈难以保护和调试。
相似地,我们也常常看到将视图层构建到营业逻辑的情形。比方,一个罕见的成绩就是将在构建视图时利用的XML剖析手艺间接使用到营业层。营业层应当对营业对象——而不是绑定到视图的特定命据暗示举行操纵。
但是,只是具有符合的组件其实不必定意味着可使您的使用程序失掉符合的分层。我们经常见到一些使用程序包括servlet、JSP和EJB组件一切这三项,但是,其次要的营业逻辑倒是在servlet层完成的,大概使用程序导航是在JSP中处置的。您必需举行严厉的代码反省偏重构您的代码,以确保使用程序的营业逻辑只在模子层(Modellayer)举行处置,使用程序导航只经由过程把持器层(Controllerlayer)举行处置,而您的视图(Views)只是将传送过去的模子对象以HTML及JavaScript的情势暗示出来。
2.在使用程序的每层都利用主动单位测试和测试办理。
不要只是测试您的图形用户界面(GUI)。分层的测试使测试及保护事情变得极为复杂。
在已往的几年中,在办法学范畴有了相称年夜的刷新,比方新呈现的被称为Agile(比方SCRUM[Schwaber]和极限编程[Beck1])的轻量级办法如今已失掉了很广泛的使用。几近一切的这些办法中的一个配合的特性是它们都倡始利用主动的测试工具,这些工具能够匡助开辟职员用更少的工夫举行回回测试(regressiontesting),并能够匡助他们制止因为不充实的回回测试酿成的毛病,因而能够用来进步程序员的事情效力。实践上,另有一种被称为Test-FirstDevelopment[Beck2]的办法,这类办法乃至倡始在开辟实践的代码之前就先编写单位测试。但是,在您测试代码之前,您必要将代码支解成一些可测试的片段。一个“年夜泥球”是难以测试的,由于它不是只完成一个复杂的易于辨认的功效。假如您的每一个代码片段完成多个方面的功效,如许的代码将难以包管其完整的准确性。
MVC框架(和J2EE中的MVC完成)的一个长处就是元素的组件化可以(实践上,相称的复杂)对您的使用程序举行单位测试。因而,您能够便利地对实体bean、会话bean和JSP自力编写测试用例,而不用思索其他的代码。如今有很多用于J2EE测试的框架和工具,这些框架及工具使得这一历程加倍复杂。比方,JUnit(是一种由junit.org开辟的开放源代码工具)和Cactus(由Apache开辟的开放源代码工具)关于测试J2EE组件都十分有效。[Hightower]具体切磋了怎样在J2EE中利用这些工具。
只管一切这些胪陈了如何完全地测试您的使用程序,可是我们仍旧看到一些人以为只需他们测试了GUI(多是基于Web的GUI,大概是自力的Java使用程序),则他们就周全地测试了全部使用程序。GUI测试很难到达周全的测试,有以下几种缘故原由。起首,利用GUI测试很难完全地测试到体系的每条路径,GUI仅仅是影响体系的一种体例,大概存在背景运算、剧本和林林总总的其他会见点,这也必要举行测试。但是,它们一般其实不具有GUI。第二,GUI级的测试是一种十分粗粒度的测试。这类测试只是在微观程度上测试体系的举动。这意味着一旦发明存在成绩,则与此成绩相干的全部子体系都要举行反省,这使得找出bug(缺点)将长短常坚苦的事变。第三,GUI测试一般只要在全部开辟周期的前期才干很好地失掉测试,这是由于只要这谁人时分GUI才失掉完全的界说。这意味着只要在前期才大概发明潜伏的bug。第四,一样平常的开辟职员大概没有主动的GUI测试工具。因而,当一个开辟职员对代码举行变动时,没有一种复杂的办法来从头测试遭到影响的子体系。这实践上倒霉于举行优秀的测试。假如开辟职员具有主动的代码级单位测试工具,开辟职员就可以够很简单地运转这些工具以确保所做的变动不会损坏已存在的功效。最初,假如增加了主动构立功能,则在主动构建过程当中增加一个主动的单位测试工具长短常简单的事变。当完成这些设置今后,全部体系就能够有纪律地举行重修,而且回回测试几近不必要人的介入。
别的,我们必需夸大,利用EJB和Web服务举行散布式的、基于组件的开辟使得测试单个的组件变得十分需要。假如没有“GUI”必要测试,您就必需举行初级(lower-level)测试。最好以这类体例入手下手测试,免得当您将散布式的组件或Web服务作为您的使用程序的一部分时,您不能不消费心机从头举行测试。
总之,经由过程利用主动的单位测试,可以很快地发明体系的缺点,而且也易于发明这些缺点,使得测试事情变得加倍体系化,因而全体的质量也得以进步。
3.依照标准来举行开辟,而不是依照使用服务器来举行开辟。
要将标准熟记于心,假如要背叛标准,要经由紧密的思索后才能够如许做。这是由于当您背叛划定规矩的时分,您所做的事变常常并非您应当做的事变。
当您要背叛J2EE能够同意您做的事变的时分,这很简单让使您蒙受不幸。我们发明有一些开辟职员研究一些J2EE同意以外的工具,他们以为如许做能够“略微”改良J2EE的功能,而他们终极只会发明如许做会引发严峻的功能成绩,大概在今后的移植(从一个厂商到另外一个厂商,大概是更罕见的从一个版本到另外一个版本)中会呈现成绩。实践上,这类移植成绩是云云严峻,乃至[Beaton]将此准绳称为移植事情的基础最好理论。
如今有好几个中央假如不间接利用J2EE供应的办法一定会发生成绩。一个罕见的例子就是开辟职员经由过程利用JAAS模块来替换J2EE平安性,而不是利用内置的遵守标准的使用程序服务器机制来举行考证和受权。要注重不要离开J2EE标准供应的考证机制,假如离开了此标准,这将是体系存在平安毛病和厂商兼容性成绩的次要缘故原由。相似地,要利用servlet和EJB标准供应的受权机制,而且假如您要偏离这些标准的话,要确保利用标准界说的API(比方getCallerPrincipal())作为完成的基本。经由过程这类体例,您将可以使用厂商供应的强平安性基本举措措施,个中,营业请求必要撑持庞大的受权划定规矩。
其他罕见的成绩包含利用不遵守J2EE标准的耐久性机制(这使得事件办理变得坚苦)、在J2EE程序中利用不得当的J2SE办法(比方线程或singleton),和利用您本人的办法办理程序到程序(program-to-program)的通讯,而不是利用J2EE内涵撑持的机制(比方JCA、JMS或Web服务)。当您将一个遵守J2EE的服务器移植到其他的服务器上,大概移植到不异服务器的新版本上,上述的计划选择将会形成有数的成绩。独一要背叛标准的情形是,当一个成绩在标准的局限内没法办理的时分。比方,布置实行准时的营业逻辑在EJB2.1呈现之前是一个成绩,在相似如许的情形下,我们倡议当有厂商供应的办理计划时就利用厂商供应的办理计划(比方WebSphereApplicationServerEnterprise中的Scheduler工具),而在没有厂商供应的办理计划时就利用第三方供应的工具。假如利用厂商供应的办理计划,使用程序的保护和将其移植到新的标准版本将是厂商的成绩,而不是您的成绩。
最初,要注重不要太早地接纳新手艺。太甚于热中接纳还没有集成到J2EE标准的其他部分大概还没有集成到厂商的产物中的手艺常会带来劫难性的成果。撑持是关头的——假如您的厂商不间接撑持一种特定的在JSR中提出的手艺,但此手艺还没有被J2EE所承受,那末您就不该该接纳此手艺。究竟,我们中的年夜多半人处置办理营业成绩,而不是促进手艺的开展。
4.从一入手下手就企图利用J2EE平安性。
启用WebSphere平安性。这使您的EJB和URL最少可让一切受权用户会见。不要问为何——照着做就是了。
在与我们互助的客户中,一入手下手就盘算启用WebSphereJ2EE平安性的主顾长短常少的,这一点一向让我们感应受惊。据我们估量约莫只要50%的主顾一入手下手就盘算利用此特征。比方,我们曾与一些年夜型的金融机构(银行、代办署理等等)互助过,他们也没有盘算启用平安性。侥幸的是,这类成绩在部署之前的反省时就得以办理.
不利用J2EE平安性是伤害的事变。假定您的使用程序必要平安性(几近一切的使用程序都必要),您敢赌博您的开辟职员可以构建出本人的平安性体系,而这个体系比您从J2EE厂商那边买来的更好。这可不是个好的赌注,为散布式的使用程序供应平安性是非常坚苦的。比方,您必要利用收集平安加密令牌把持对EJB的会见。以我们的履历看来,年夜多半本人构建的平安性体系是不平安的,而且有严重的缺点,这使产物体系极为懦弱。
一些不利用J2EE平安性的来由包含:忧虑功能的下落,信任其他的平安性(比方NetegritySiteMinder)能够代替J2EE平安性,大概是不晓得WebSphereApplicationServer平安特征及功效。不要堕入这些圈套当中,特别是,只管像NetegritySiteMinder如许的产物可以供应优异的平安特征,可是仅仅其本身不成能回护全部J2EE使用程序。这些产物必需与J2EE使用程序服务器团结起来才大概周全地回护您的体系。
其他的一种罕见的不利用J2EE平安性的缘故原由是:基于脚色的模子没有供应充足的粒度会见把持以满意庞大的营业划定规矩。只管现实是如许的,但这也不该该成为不利用J2EE平安性的来由。相反地,应当将J2EE考证及J2EE脚色与特定的扩大划定规矩分离起来。假如庞大的营业划定规矩必要做出平安性决议,那就编写响应的代码,其平安性决议要基于能够间接利用的和牢靠的J2EE考证信息(用户ID和脚色)。
5.创立您所晓得的。
重复的开辟事情将使您可以渐渐地把握一切的J2EE模块。要从创立小而复杂的模块入手下手而不是从一入手下手就即刻触及到一切的模块。
我们必需供认J2EE是复杂的系统。假如一个开辟小组只是入手下手利用J2EE,这将很难一会儿就可以把握它。在J2EE中有太多的观点和API必要把握。在这类情形下,乐成把握J2EE的关头是从复杂的步骤入手下手做起。
这类办法能够经由过程在您的使用程序中创立小而复杂的模块来失掉最好的完成。假如一个开辟小组经由过程创立一个复杂的域模子和后真个耐久性机制(大概利用的是JDBC),而且对其举行了完全的测试,这会加强他们的自傲心,因而他们会利用该域模子往把握利用servlet和JSP的前端开辟。假如一个开辟组发明有需要利用EJB,他们也会相似地入手下手在容器办理的耐久性EJB组件之上利用复杂的会话Facades,大概利用基于JDBC的数据会见对象(JDBC-basedDataAccessObjects,DAO),而不是跳过这些往利用加倍庞大的机关(比方动静驱动bean和JMS)。
这类办法并非甚么新办法,可是很少有开辟组以这类体例来培育他们的妙技。相反地,多半开辟组因为实验即刻就构建一切的模块,同时触及MVC中的视图层、模子层和把持器层,如许做的了局是他们常常会堕入进度的压力当中。他们应当思索一些急迅(Agile)开辟办法,比方极限编程(XP),这类开辟办法接纳一种增量进修及开辟办法。在XP中有一种称为ModelFirst的历程,这个历程触及到起首构建域模子作为一种机制来构造和完成用户场景。基础说来,您要构建域模子作为您要完成的用户场景的主要部分,然后在域模子之上构建一个用户界面(UI)作为用户场景完成的了局。这类办法十分合适让一个开辟组一次只学到一种手艺,而不是让他们同时面临良多种情形(大概让他们读良多书),这会令他们溃散的。
另有,对每一个使用程序层反复的开辟大概会包括一些得当的形式及最好理论。假如您从使用程序的底层入手下手使用一些形式如数据会见对象和会话Facades,您就不该该在您的JSP和其他视图对象中利用域逻辑。
最初,当您开辟一些复杂的模块时,在入手下手的早期就能够对您的使用程序举行功能测试。假如直到使用程序开辟的前期才举行功能测试的话,这常常会呈现劫难性的成果。
6.当利用EJB组件时,一直利用会话Facades。
决不要将实体bean间接表露给任何用户范例。对实体bean只可使用当地EJB接口(LocalEJBinterfaces)。
当利用EJB组件时,利用一个会话Facades是一个确认无疑的最好理论。实践上,这个通用的理论被普遍地使用就任何散布式的手艺中,包含CORBA、EJB和DCOM。从基本上讲,您的使用程序的散布“交织地区”越是底层化,对小块的数据因为屡次反复的收集中继酿成的工夫损耗就越少。要到达这个目标的办法就是:创立年夜粒度的Facades对象,这个对象包括逻辑子体系,因此能够经由过程一个办法挪用就能够完成一些有效的营业功效。这类办法不仅可以下降收集开支,并且在EJB外部经由过程为全部营业功效创立一个事件情况也能够年夜年夜地削减对数据库的会见次数。
EJB当地接口(从EJB2.0标准入手下手利用)为共存的EJB供应了功能优化办法。当地接口必需被您的使用程序显式地举行会见,这必要代码的改动和避免今后设置EJB时必要使用程序的改动。因为会话Facades和它包括的全部EJB关于相互来讲都应当是当地的,我们倡议对会话Facades前面的实体bean利用当地接口。但是,会话Facades自己的完成(典范例子如无形态会话bean)应当计划为远程接口。
为了功能的优化,能够将一个当地接口增加到会话Facades。如许做使用了如许一个现实:在年夜多半情形下(最少在Web使用程序中),您的EJB客户端和EJB会配合存在于统一个Java假造机(JVM)中。别的一种情形,假如会话Facades在当地被挪用,可使用J2EE使用服务器设置优化(configurationoptimizations),比方WebSphere中的“NoLocalCopies”。但是,您必需注重到这些可供选择的计划会将交互办法从按值传送(pass-by-value)改动为按援用传送(pass-by-reference)。这大概会在您的代码中发生很奇妙的毛病。当您要使用这些计划时,您应当在一入手下手就思索其可行性。
假如在您的会话Facades中利用远程接口(而不是当地接口),您也能够将一样的会话Facades在J2EE1.4中以兼容的体例作为Web服务来设置。这是由于JSR109(J2EE1.4中的Web服务部署部分)请求利用无形态会话bean的远程接口作为EJBWeb服务和EJB完成的接口。如许做是值得的,由于如许做能够为您的营业逻辑增添客户端范例的数目。
7.利用无形态会话bean,而不是有形态会话bean。
如许做可使您的体系经得起毛病的停止。利用HttpSession存储和用户相干的形态。
以我们的概念看来,有形态会话bean的观点已过期了。假如您细心对其思索一下,一个有形态会话bean实践上与一个CORBA对象在系统布局上是完整不异的,不过就是一个对象实例,绑定到一个服务器,而且依附于服务器来办理其性命周期。假如服务器封闭了,这类对象也就不存在,那末这个bean的客户真个信息也就不存在。
J2EE使用服务器为有形态会话bean供应的妨碍转移(failover)可以办理一些成绩,可是有形态的办理计划没有没有形态的办理计划易于扩大。比方,在WebSphereApplicationServer中,对无形态会话bean的哀求,是经由过程对部署无形态会话的成员集群举行均衡加载来完成。相反地,J2EE使用服务器不克不及对有形态bean的哀求举行均衡加载。这意味着您的集群中的服务器的加载历程会是不平衡的。别的,利用有形态会话bean将会再增加一些形态到您的使用服务器上,这也是欠好的做法。如许就增添了体系的庞大性,而且在呈现妨碍的情形下使成绩变得庞大化。创立强健的散布式体系的一个关头准绳是只管利用无形态举动。
因而,我们倡议对年夜多半使用程序利用无形态会话bean办法。任安在处置时必要利用的与用户相干的形态应当以参数的情势传送到EJB的办法中(而且经由过程利用一种机制如HttpSession来存储它)大概从耐久性的后端存储(比方经由过程利用实体bean)作为EJB事件的一部分来举行检索。在符合的情形下,这个信息能够缓存到内存中,可是要注重在散布式的情况中保留这类缓存所潜伏的应战性。缓存十分合适于只读数据。
总之,您要确保从一入手下手就要思索到可舒展性。反省计划中的一切假想,而且思索到当您的使用程序要在多个服务器上运转时,是不是也能够一般运转。这个划定规矩不仅合适上述情形的使用程序代码,也合用于如MBean和其他办理界面的情形下。
8.利用容器办理的事件。
进修一下J2EE中的两阶段提交事件,而且利用这类体例,而不是开放您本人的事件办理。容器在事件优化方面几近老是对照好的。
利用容器办理的事件(CMT)供应了两个关头的上风(假如没有容器撑持这几近是不成能的):可组合的事情单位和强健的事件举动。
假如您的使用程序代码显式地利用了入手下手和停止事件(大概利用javax.jts.UserTransaction大概乃至是当地资本事件),而未来的请求必要组合模块(大概会是代码重构的一部分),这类情形下常常必要改动事件代码。比方,假如模块A入手下手了一个数据库事件,更新数据库,随后提交事件,而且有模块B做出一样的处置,请思索一下当您在模块C中实验利用上述两个模块,会呈现甚么情形呢?如今,模块C正在实行一个逻辑举措,而这个举措实践大将挪用两个自力的事件。假如模块B在实行中失利了,而模块A的事件仍旧能被提交。这是我们所不但愿呈现的举动。假如,相反地,模块A和模块B都利用CMT的话,模块C也能够入手下手一个CMT(一般经由过程设置形貌符),而且在模块A和模块B中的事件将是统一个事件的隐含部分,如许就不再必要庞大的重写代码的事情了。
假如您的使用程序在统一个操纵中必要会见多种资本,您就要利用两阶段提交事件。比方,假如从JMS行列中删除一个动静,而且随后更新基于这条动静的记录,这时候,要包管这两个操纵城市实行或都不会实行就变得尤其主要。假如一条动静已从行列中被删除,而体系没有更新与此动静相干的数据库中的记录,那末这类体系是不不乱的。一些严峻的客户及贸易纠葛源自纷歧致的形态。
我们经常看到一些客户使用程序试图完成他们本人的办理计划。大概会经由过程使用程序的代码在数据库更新失利的时分“打消”对行列的操纵。我们不倡始如许做。这类完成要比您最后的设想要庞大很多,而且另有很多其他的情形(设想一下假如使用程序在实行此操纵的过程当中俄然溃散的情形)。作为替换的体例,应当利用两阶段提交事件。假如您利用CMT,而且在一个单一的CMT中会见两阶段提交的资本(比方JMS和年夜多半数据库),WebSphere将会处置一切的庞大事情。它将确保全部事件被实行大概都不被实行,包含体系溃散、数据库溃散或其他的情形。实在如今事件日记中保留着事件形态。当使用程序会见多种资本的时分,我们怎样夸大利用CMT事件的需要性都不为过。
9.将JSP作为暗示层的首选。
只要在必要多种暗示输入范例,而且输入范例被一个单一的把持器及后端撑持时才利用XML/XSLT。
我们常听到一些争辩说,为何您选择XML/XSLT而不是JSP作为暗示层手艺。选择XML/XSLT的人的概念是,JSP“同意您将模子和视图夹杂在一同”,而XML/XSLT不会有这类成绩。遗憾的是,这类概念其实不完整准确,大概最少不像白与黑那样分的分明。实践上,XSL和XPath是编程言语。XSL是图灵完成的(Turing-complete),只管它不切合年夜多半人界说的编程言语,由于它是基于划定规矩的,而且不具有程序员习气的把持工具。
如今的成绩是既然赐与了这类天真性,开辟职员就会使用这类天真性。只管每一个人都认同JSP使开辟职员简单在视图中到场“相似模子”的举动,而实践上,在XSL中也有大概做出一些一样的事变。只管从XSL中举行会见数据库如许的事变会十分坚苦,可是我们已经见到过一些非常庞大的XSLT款式表实行庞大的转换,这实践上是模子代码。
但是,应当选择JSP作为首选的暗示手艺的最基础的缘故原由是,JSP是如今撑持最普遍的、也是最被普遍了解的J2EE视图手艺。而跟着自界说标志库、JSTL和JSP2.0的新特征的引进,创立JSP变得加倍简单,而且不必要任何Java代码,和能够将模子和视图明晰的分别开。在一些开辟情况中(如WebSphereStudio)到场了对JSP(包含对换试的撑持)的壮大撑持,而且很多开辟职员发明利用JSP举行开辟要比利用XLS复杂,一些撑持JSP的图形计划工具及其他特性(特别在JSF如许的框架下)使得开辟职员能够以所见即所得的体例举行JSP的开辟,而关于XSL偶然不简单做到。
最初一个要审慎思索利用JSP的缘故原由是速率成绩。在IBM所作的对照XSL和JSP绝对速率的功能测试显现:在年夜多半情形下,JSP在天生一样的HTML的时分,要比XSL快好几倍,乃至利用编译过的XSL也是云云。只管多半情形下这不是成绩,但在功能请求很高的情形下,这就会成为成绩。
但是,这也不克不及说,您永久也不要利用XSL。在一些情形下,XSL可以暗示一组流动的数据,而且能够基于分歧的款式表来以分歧的体例显现这些数据的才能是显现视图的最好办理计划。但是,这只是一种破例的情形,而不是通用的划定规矩。假如您只是天生HTML来表达每个页面,那末在年夜多半情形下,XSL是一种不用要的手艺,而且,它给您的开辟职员所带来的成绩远比它所能办理的成绩多。
10.当利用HttpSession时,只管只将以后事件所必要的形态保留个中,其他内容不要保留在HttpSession中。
启用会话耐久性。
HttpSessions关于存储使用程序形态信息长短常有效的。其API易于利用和了解。遗憾的是,开辟职员经常忘记了HttpSession的目标——用来坚持临时的用户形态。它不是恣意的数据缓存。我们已见到过太多的体系为每一个用户的会话放进了大批的数据(到达兆字节)。那好了,假如同时有1000个登录体系的用户,每一个用户具有1MB的会话数据,那末就必要1G大概更多的内存用于这些会话。要使这些HTTP会话数据较小一些,否则的话,您的使用程序的功能将会下落。一个约莫对照符合的数据量应当是每一个用户的会话数据在2K-4K之间,这不是一个硬性的划定规矩,8K仍旧没有成绩,可是明显会比2K时的速率要慢。必定要注重,不要使HttpSession酿成数据聚积的场合。
一个罕见的成绩是利用HttpSession缓存一些很简单再创立的信息,假如有需要的话。因为会话是耐久性的,举行不用要的序列化和写进数据是一种很奢靡的决意。相反地,应当利用内存中的哈希表来缓存数据,而且在会话中保留一个对此数据举行援用的关头字。如许,假如不克不及乐成登录到别的的使用服务器的话,就能够从头创立数据。
当谈及会话耐久性时,不要健忘要启用这项功效。假如您没有启用会话耐久性,大概服务器由于某种缘故原由中断了(服务器妨碍或一般的保护),则一切此使用服务确当前用户的会话将会丧失。这是件使人十分不乐意的事变。用户不能不从头登录,而且从头做一些他们已经已做过的事变。相反地,假如启用了会话耐久性,WebSphere会主动将用户(和他们的会话)移到别的一个使用服务器上往。用户乃至不晓得会有这类事变的产生。我们已经见到过一些产物体系由于存在于当地代码中使人难以忍耐的bug(不是IBM的代码!)而俄然溃散的情形,这这类情形下,上述功效仍旧能够运转优秀。
11.在WebSphere中,利用静态缓存,并利用WebSphereservlet缓存机制.
经由过程利用这些功效,体系功能能够失掉很年夜的进步,而开支是很小的。而且不影响编程模子。
经由过程缓存来进步功能的优点是尽人皆知的事变。遗憾的是,以后的J2EE标准没有包含一种用于servlet/JSP缓存的机制。但是,WebSphere供应了对页面和片段缓存的撑持,这类撑持是经由过程其静态缓存功效来完成的,而且不必要对使用程序作出任何改动。其缓存的战略是声明性的,并且其设置是经由过程XML设置形貌符来完成的。因而,您的使用程序不会遭到影响,并坚持与J2EE标准的兼容性和移植性,同时还从WebSphere的servlet及JSP的缓存机制中失掉功能的优化。
从servet及JSP的静态缓存机制失掉的功能的进步是不言而喻的,这取决于使用程序的特征。Cox和Martin[Cox]指出对一个现有的RDF(资本形貌格局)站点择要(RSS)servlet,当利用静态缓存时,其功能能够进步10%。请注重这个实行只触及到一个复杂的servlet,这本性能的增加量大概其实不能反应一个庞大的使用程序。
为了更多地进步功能,将WebSphereservlet/JSP了局缓存与WebSphere插件ESIFragment处置器、IBMHTTPServerFastResponseCacheAccelerator(FRCA)和EdgeServer缓存功效集成在一同。关于沉重的基于读取的事情负荷,经由过程利用这些功效能够失掉很多分外的优点。
12.为了进步程序员的事情效力,将CMP实体bean作为O/R映照的首选办理计划.
经由过程WebSphere框架(readahead、缓存、断绝级别等)优化功能。假如大概,有选择的使用一些形式来到达进步功能的目标,比方Fast-Lane浏览器[Marinescu]。
对象/干系(O/R)映照是利用Java创立企业级的使用程序的基本。几近每一个J2EE使用程序都必要一些范例的O/R映照。J2EE厂商供应一种O/R映照机制,这类机制在分歧的厂商间是可移植的,高效的,而且可以被一些尺度及工具很好地撑持。这就是EJB标准中的CMP(容器办理的耐久性)部分。
初期的CMP完成以体现欠安及不撑持很多SQL布局而著称。但是,跟着EJB2.0及2.1标准的呈现,和被一些厂商所采取,而且跟着像IBMWebSphereStudioApplicationDeveloper的呈现,这些成绩已不再是成绩了。
CMPEJB组件如今已被普遍地使用于很多高功能的使用程序中。WebSphere包含一些优化功效以进步EJB组件的功能,优化功效包含:对性命周期的缓存和read-ahead才能。这二者优化功效都是设置时的选项,而且不必要对使用程序举行修正大概影响可移植性。
处于缓存形态的性命周期缓存CMP形态数据并供应基于工夫的有效性。从处于缓存形态的性命周期失掉的功能进步能够到达选项A的缓存功能,而且仍旧能够为您的使用程序供应可舒展性。Read-ahead才能和容器办理的干系分离利用。这个特征经由过程在不异的查询中随便地检索相干的数据作为父数据而削减与数据库的交互。假如相干的数据要经由过程利用并发的查询来会见的话,这类办法能够失掉功能的改善。[Gunther]供应了具体的形貌和经由过程这些特征失掉的功能进步的细节。
别的,为了完整优化您的EJB组件,当指定断绝级别时要出格注重。尽量利用最低的断绝级别,而且仍旧坚持您的数据的完全性。较低的断绝级别能够供应最好的功能,而且能够下降呈现数据库逝世锁的伤害。
这是今朝最有争议的最好理论。已有大批的文章歌颂CMPEJB,一样的贬低声也不停于耳。但是,这里最基础的成绩是数据库开辟是坚苦的。当您入手下手利用任何耐久性办理计划之前,您必要把握查询和数据库锁定怎样事情这些基本常识。假如您选择利用CMPEJB,您要确保您已经由过程一些书本(比方[Brown]和[Barcia])晓得怎样利用它们。在锁定及争用方面有一些奇妙的交互难以了解,可是,在您泯灭必定的工夫及勉力后会将其把握的。
停止语
在这个冗长的择要中,我们已向您先容了J2EE中的中心形式和最好理论,这使得J2EE开辟成为一种可办理的历程。只管我们并没有给出一切在理论中利用这些形式的需要细节,可是我们但愿可以给您充足的指导和引导,以匡助您决意下一步要做甚么。
j2EE和asp比较,其实也没什么比的,原因和我上面说那些比较差不了多少,也是稳定性,安全性,J2EE比asp高,速度上比不过asp,asp也是延续着它的拖拽控件的方法,提高速度。 |
|