做杂志的模板下载网站有哪些,平潭做网站,建筑清单网,网页打不开但是有网什么原因win10java ee技术在过去的几个月中#xff0c;我们经历了这个决策过程#xff1a;为Java平台上的企业开发选择哪种技术堆栈#xff1f; 有多种选择。 但是#xff0c;我们深入讨论的是#xff1a;纯Java EE 6堆栈与带有Java EE的Spring。 以下博客文章总结了当您考虑这些技术堆… java ee技术 在过去的几个月中我们经历了这个决策过程为Java平台上的企业开发选择哪种技术堆栈 有多种选择。 但是我们深入讨论的是纯Java EE 6堆栈与带有Java EE的Spring。 以下博客文章总结了当您考虑这些技术堆栈选项之一时发现的有趣的关键问题。 我不会试图说服某人选择两者之一。 这对我来说很重要我想分享的是决策过程和关键论点。 什么是“标准” 在我们的讨论中“标准”一词非常重要特别是对于执行管理层而言。 我认为这使决策者对保护投资充满热情。 但是什么是标准在Java生态系统中我们可以认为什么是标准 Codecentric AG的创始人兼董事会成员Mirko Novakovic写了一篇非常有趣的博客文章名为“ Java EE vs Spring。 或者什么是标准 ” Mirko指出以下内容 对他来说标准是建立接受和主导的东西 遵循此定义仅将某些Java EE API例如Servlet规范视为标准因为它们已广泛应用于Java生产技术领域 他过去曾说过某些Java EE标准API几乎没有投资保护例如EJB规范过去十年中大量API发生了变化 他还声称JPA和JSF的1.0版本不足以满足大型企业开发项目中的技术要求。 他将CDI视为另一个年轻的标准它需要证明其长期稳定性然后才能被视为Java企业应用程序中的标准IOC机制。 因此他目前的结论是Sping和Hibernate仍然是Java企业开发的“实际”标准。 Mirko描述了一个有效的观点。 另一个有效的观点是在Java规范请求JSR中指定和发布的所有唯一的API都可以视为标准。 应用服务器供应商根据这些JSR构建产品。 因此如果Java开发人员使用这些标准API他们可以构建可在任何应用程序服务器平台上运行的Web应用程序。 在Java EE 6中他们可以构建企业级Web应用程序而无需进一步依赖于第三个库。 结果是一个非常轻便的Web应用程序WAR或EAR文件仅包含您开发的代码。 那是Java EE的情况也是有效和结论性的。 当您必须决定在编程模型中使用哪些API时对您来说最重要的是什么 有很多决策参数例如简单性API的完整性改进的生产稳定性等等。 我们在研究中列出了一长串参数。 其中一些比其他一些更为重要它们是API的成熟度供应商独立性生产就绪性投资保护和共同判断。 标准API的生命周期 我们的假设是每个API进入Java EE标准时都会经历理想的 生命周期 我们在过去已经观察到。 这些阶段是NewbyStormStabalizeMaturalDead。 标准API的第一个 Newby 版本1.0几乎没有功能。 通常仅仅满足大型开发项目的功能和性能的技术要求是不够的。 这是Mirko反对CDI或JPA 1.0的观点。 有些人使用这些API但他们还必须编程许多变通方法以获取所需的全部功能例如JPA 1.0中的第二级缓存。 这些阶段的经验教训进入了后续的API版本因此API有时会变得不稳定。 增加了功能减少了采用简化的API等。 如果客户希望遵循该标准那么这种动荡且不确定的风暴阶段会导致迁移成本增加。 即使2.0版本向下兼容使用不错的新功能代替许多变通办法也意味着重构工作。 如果该API并非没有问题兼容的API更改会强制执行迁移工作则别无选择。 过了一会儿但是API变得成熟这些重构成本下降该API进入stabalization的阶段。 一个成熟的 API始终具有较低的迁移和重构成本因为未应用任何基本更改。 一段时间后不再使用某种技术因为它已被其他创新的API所取代。 技术已死了–这些API不再投资社区 停止了该项目。 图1显示了理想的API生命周期。 图1理想的Java EE API生命周期 生命周期模型的关键假设是您决定越早使用API标准则在后续版本中增强API时可能要付出的重构成本就更多。 因此建议是您必须判断生命周期中Java EEAPI的状态。 然后您决定是否要使用成熟的API和更低的制罐成本。 还是您想成为利用技术束缚的先驱之一。 尽早采用的优势之一可能是早日实现更高的开发效率与其他标准API的更高集成度或开发咨询知识。 我们已决定仅使用成熟的API我们不希望与“ Newby”状态API相关的迁移成本。 我们的信任度很低因为我们在EJB时代遭受了很多苦难。 如果我们回顾一些Java EE标准的历史则与API稳定性相关的变化是巨大的。 因此我们宁愿等到API成熟并且已成为生产中大型应用程序系统的成熟技术。 如果我们认为Java EE API已经成熟则可以考虑使用它。 独立性开发运营和OE供应商 对我们而言架构决策中的另一个重要因素是我们希望为以后的架构设计或实施决策提供最大的灵活性。 那是什么意思 例如如果您选择的技术堆栈是应用程序服务器的一部分那么您的应用程序开发部门基础架构人员和原始设备OE供应商之间的关系将非常紧密。 为什么 因为新的应用程序服务器版本包含您在业务应用程序中使用的新API版本。 结果是当您决定使用新版本的应用程序服务器时可能必须更改现有代码。 所有这些降低了灵活性。 另外OE供应商可能会急着迁移您因为“如果您想拥有我们应用程序服务器的此独特监视或集成功能则必须使用最新版本的XY Java EE服务器”。 OE供应商通常会对他们感兴趣因为他们希望您使用最新版本。 对于他们来说支持更少的生产版本只是更便宜。 它为他们带来更少的维护成本和更高的咨询收入。 我们在生产中运行了50多个Java EE应用程序。 出于上述原因保持独立于运行时基础结构对我们非常重要。 因此我们通常更喜欢业务应用程序和应用程序服务器之间的“层”。 换句话说我们通常不直接使用Newby API我们通常有一个包装它们的包装器API参见图2。 该包装器用作构建业务应用程序的API。 包装器API可以是Spring框架也可以是您自己的一组自定义框架API。 这样当我们分别移动到新的应用程序服务器版本或Java EE版本时进行所需的更改将更容易更有效。 包装器吸收了Java EE API的更改使我们免去了更改50个应用程序的负担。 相反我们只在中央位置进行一次更改。 我们的开发小组不受应用程序服务器升级的影响。 OE供应商和Java Communication ProcessJCP不会影响我们的决定和努力。 基础架构的生产就绪性或现在还是以后 您的应用服务器是否有生产就绪版本可以实现新的Java EE 6标准 在我们的情况下IBM WebSphereZ系列上没有任何Java EE 6版本。 因此如果我们还不能在生产环境中运行应用程序那么思考Java EE 6几乎没有任何意义。 您必须决定是现在还是以后使用某种技术。 例如作为IOC机制的CDIJSR 299/330对于大型应用程序还不够成熟。 因此你可能要选择像Spring框架或谷歌吉斯的替代品来完成这项工作如果你想现在已经送到您的客户端效益分析值。 投资保护或兼容性低下 我已经在前面提到过直接将Java EE API用于许多生产应用程序可能是50或100可能会降低设计和实现决策的灵活性。 在研究投资保护时同样的论点也适用。 对我而言投资保护主要涉及在特定时期内较低的技术重构成本。 您想花费金钱来实现业务价值您想专注于实现业务功能。 你不想花费在生活必需品技术的精力例如发布版本升级平台迁移开发自定义的API。 为了实现这一点选择正确的开发API至关重要。 根据我们的生命周期模型一个不错的选择是在生命周期的长期成熟阶段开始时选择API。 这降低了重构成本从而增加了投资保护。 我们已经解释了Java EE不仅提供成熟的API。 例如CDI在其JSR 299/330版本中还不成熟。 解决该难题的一种可能的方法是组合来自不同来源的API您可以为业务应用程序配置自己的API集。 如果您使用自己的一组 真实的标准API则可以保护您的投资。 我说的是您自己的一套因为您可能会使用混合技术堆栈 图2一些成熟的Java EE API例如ServletJPA 2.0一些实际标准例如Spring IOC和一些专有的自定义API作为围绕Newby Java EE API的包装而开发的。 最重要的是这些API支持生产应用程序的低兼容性 。 当您要移至新的Java EE 应用程序服务器版本 时必须找到一组API这些API可使您免于繁重的迁移工作 。 图2用于Java企业开发的混合技术堆栈 共同判断 我做决定时要做的事情就是共同判断。 其他专家怎么看 他们有什么意识形态 他们对一个或另一个建议有什么兴趣 如果查看像Spring Framework这样的大型Java企业开发框架您会发现它们使用标准的Java EE API但仅使用它们认为已经成熟的API。 对于我是否使用特定的API这是一个很好的提示。 无论您是查看Spring还是观察其他框架都不会满足。 关键是您可以对照其他资深最好是独立的专家的意见来验证您的意见。 摘要 当您决定使用哪种技术堆栈时有一长串参数。 我在本文中描述的内容在我们的决策过程中非常重要。 我们的结论是目前最好的方法是使用混合技术堆栈。 一些API是事实上的标准一些是Java EE标准其他是我们开发的自定义API。 我们的主要目标是随着时间的推移以较低的重构成本保持灵活性。 关于标准的最后思考您是否曾经问过自己遵循标准是否真的很重要 有时我的印象是对某些人来说使用标准是接近绝对真理的事情是普遍要做的事情。 水是湿的天空是蓝色的使用标准是正确的。 你知道我想说什么吗 所有这些事实上的标准例如Spring和Hibernate如何成为标准 答案是因为有人有勇气使用它而其他人包括Java EE则紧随其后。 “标准”是社区中很大一部分用来在生产中运行大型应用程序的工具。 标准不一定是Java EE标准。 过去Java EE标准遵循事实上的标准框架例如HibernateSpring。 在开源框架中任何新技术很可能首先达到一定的成熟度。 然后它们将成为Java EE标准。 这是因为至少在最近十年中绝大多数Java技术创新都源于社区。 参考 Java EE 6与Spring Framework我们JCG合作伙伴 Niklas的技术决策过程。 相关文章 从Spring到Java EE 6 Java EE6 CDI命名组件和限定符 Java EE6装饰器在注入时装饰类 Spring Data JPA的持久层 Spring MVC3 Hibernate CRUD示例应用程序 翻译自: https://www.javacodegeeks.com/2012/01/java-ee-6-vs-spring-framework.htmljava ee技术
