在成为主流开发语言的
或者说现在已经成为了主流开发语言
在JAVA语言平台上也出现了多种开发模型对于刚入门JAVA
员来说也许面对这么多开发模型会眼花缭乱不知道该如何选择笔者刚开始接触JAVA语言时候没有多少开发模型可以选择而前几年笔者也遇到了这个问题可选开发模型比较多笔者必须选择个开发模型作为未来自己主攻方向
人精力是有限特别是我们做开发我们要把有限精力花在刀口上笔者在这里向大家推荐EJB开发模型
这个EJB本质上就是个被管理组件存在于J2EE容器中由J2EE容器进行创建、控制和销毁J2EE容器复杂控制当前存在EJB数目和EJB所使用资源在重负载情况下即使是客户端正在使用EJB也将被返回到例子池如此话这个EJB例子还可以供其他客户端使用从而提高EJB例子利用率虽然J2EE官方也是推荐使用EJB但是这并不是个强制性措施开发人员除了利用EJB的外还可以利用JSP或者单机版JAVA应用等等但是如果应用需要不断升级、性能要求比较高等等那么笔者就向大家推荐使用EJB主要有如下 3个方面原因、可以隐藏管道代码现在音乐喷泉在各地迅速
被采用成为高科技景观个代表的作员在开发这个应用时候人员需要用到这些管道但是并不需要知道这些水管具体走向这不是开发人员所需要关注内容开发人员的需要直接使用这些现成管道即可我们把这些管道就叫做“管道代码”其实开发人员有时候就好像个工业设计师工业设计师在设计洗澡用花撒水笼头时候其根本不用关心自来水管道为什么呢？自来水管道都是采用同标准水压话也是国家有个强制性标准为此在需要使用管道时候设计者的需要直接引用这些标准化参数即可在早期些开发模型中如最原始CORBA开发模型开发人员不得不便写大量代码来完成同Corba环境交互、连接、注册过程其实这些代码就是通常所说管道代码而如果采用EJB模型话则可以最大限度减少这些管道代码编写工作如
开发人员通过声明属性就可以无需要编写代码来控制这些功能即可指定组件事务性为；不用通过编写管道代码来定义EJB组件的间关系以及所需要用到资源可部署J2EE应用在部署描述信息中定义了多个EJB组件的间关系同时定义了EJB组件所需要用到资源；如每个Bean都遵循个定义声明周期和套规则为此开发人员不需要知道“管道”设计而只需要知道管道接口参数即可如此话系统代码和应用代码的间就是两个互相独立内容显然
通过J2EE提供EJB组件可以让开发人员将精力集中在业务代码编写上而尽量减少编写管道代码这不仅可以提高应用开发效率而且把管道代码和应用代码独立开来也利于后续调试和维护这就是笔者推荐使用EJB模型来开发JAVA应用第个原因2、EJB预定义了
些复杂处理机制在应用
开发过程中或多或少有些共性内容如需要进行应用生命周期管理需要进行命名和注册需要进行事务管理等等如果每次在开发应用时候都需要从零开始来开发这些功能那么工作量就会很大而且代码重复利用性也会比较差为了解决这些问题EJB提供了些预定义服务把些应用开发中要用到服务集成到J2EE开发环境中需要用到这些服务时候开发人员的需要声明下或者通过少量代码就可以
这些服务实现些复杂控制管理机制如在应用
开发中为了保持数据致性事务管理机制是必须要实现个机制如果在应用层面没有实现事务管理机制话则当同个业务涉及到多条记录时候很容易破坏数据致性而如果从零开始来编写事务处理机制代码话那么工作量会很大在EJB容器服务中就预先提供了事务管理解决方式开发人员可以凭借这个预定义地解决方案轻松创建事务、处理和控制事务等等如在应用
开发中命名和注册也是很麻烦件工作而EJB也提供另个命名和注册容器EJB容器和服务器为EJB提供了对命名服务访问远程和本地客户端使用这些服务来寻找EJB；EJB组件本身也使用这些服务来查询自身所需要资源也就好说开发人员在应用开发中不用通过代码来实现命名和注册服务而直接EJB组件中命名和注册容器即可这个容器会自动生成相关代码来完成所需要实现功能另外
EJB组件还提供了生命周期管理容器、安全性和访问控制容器、持久性容器等等通过这些容器可以让开发人员少写大量代码不仅可以提高开发效率而且同意了这些基础性内容解决方案这也有利于后来人员了解源代码有利于应用管理软件Software后续升级3、用户接口和底层业务功隔离
在企业管理中共性和个性是并存
这也体现在了企业管理软件Software上如同家企业如果管理者文化背景区别其或许多同个业务具有区别管理方式这个用我们开发人员专业术语来讲就是用户接口区别但是其背后管理模型是相同也就是说其业务功能是相同如利用JAVA语言开发个订单管理系统其订单处理机制是相同都在数据库中建立相关纪录并在保存记录的前进行数据有效性审核但是区别订单类型其处理方式可能稍有区别如对于预付订单必须要先收到客户款项才能够下订单给生产部门安排生产或者仓库部门准备出货；如对于仓库订单则在流程处理上不需要经过生产而直接转到仓库出货等等也就说是10种区别类型订单其80%功能是相同而又20%内容由于管理方式或者其他原因而有所区别在这种情况下难道要写十个区别代码来实现这十种区别需求吗？在EJB开发模型中不用这么复杂
EJB允许独立于表达层开发和部署业务功能如上面这个订单管理需求开发人员可以利用EJB模型来实现底层功能(80%共性内容)然后再无需重新设计或者开发整个应用或者销售订单管理模块情况下可以利用区别用户接口来实现用户区别需求这就好像父母和子女关系现把父母特性定义好然后再根据区别需要生养区别子女即可(用户接口)由于子女继承了父母全部特性那么只需要把用户需要实现些个性特点嫁接到子女身上即可所以这种业务需求和业务功能相分离各自独立特征是EJB开发模型最大优势开发人员可以利用EJB实现分布式应用将用户接口和底层业务功能隔离开来
最新评论