网站建设投标方案,建网站的手机软件,铜陵市住房和城乡建设局网站,ps做网站效果图尺寸如何自从我担任技术决策职务以来已经过去了一年多#xff0c;很高兴看到我仍然与之保持着完美的和谐。 几个月前#xff0c;我在KaiWhner的一个不错的博客中写了一个有关JEE与Spring的答案。 如果观点没有不同#xff0c;那么讨论的附加值在哪里#xff1f; 我确实同意Kai的许多… 自从我担任技术决策职务以来已经过去了一年多很高兴看到我仍然与之保持着完美的和谐。 几个月前我在KaiWähner的一个不错的博客中写了一个有关JEE与Spring的答案。 如果观点没有不同那么讨论的附加值在哪里 我确实同意Kai的许多观点。 但是对我而言它不是Java EE *或* Spring如最近这篇文章中所建议的也不是功能的问题因为最终功能在两种体系结构选项及其相应的生态系统中都进行了很好的分类。 如果缺少某些东西那里的人已经编写了一个好的库并将其开源。 这也不是“重量重”或“重量轻”的问题。 几年后由于向下兼容性要求任何框架都将承担一些固定费用。 由于这些原因本博客将不是有关Spring和Java EE的内容和原因的技术文章。 首先我认为整个问题归结为您要在其中放置用作开发API的框架库以编写业务应用程序的问题在服务器库目录中或在WEB-WAR / EAR文件中INF / lib。 图2Spring和Java EE应用程序的简化开发架构 Spring和“纯” Java EE应用程序之间最大的相关差异在于Spring应用程序中的开发框架API是部署到任意Java运行时的Java应用程序WAR或EAR文件的一部分。 相反纯Java EE应用程序仅包含业务代码并且应用程序框架是应用程序服务器的一部分。 因此业务应用程序直接在应用程序服务器API上工作。 除了这些纯粹的方案外当今的大多数Java企业应用程序还使用Java EE和Spring API的混合。 几乎可以在任何不同的主题Web服务IoC容器GUI等中做出Java EE *或* Spring决策。 还有针对Java EE和Spring应用程序的纯运行时环境兼容Java EE的服务器Redhat JBossIBM WebSphereOracle WebLogic和VMWare的vFabric tc Server。 因此在一个绿色领域人们可以选择纯Java EE应用程序体系结构而不是纯Spring应用程序体系结构。 但是如前所述大多数应用程序都是混合运行的。 我尚未进行过评估但是我怀疑许多应用程序在带有Spring IoC容器的Java EE或Tomcat服务器环境中运行。 与其使用* only * Java EE或完整的Spring堆栈不如使用成熟的Java EE和Spring API的均衡组合来实现。 Java EE的优势是各方在书面过程中建立的开放标准。 因此尽管许多项目仅使用少量的Java EE API但为此平台构建应用程序却非常受欢迎。 需要注意的另一个重要事实是每个明智的Java打包软件供应商都支持主要的Java EE平台。 因此许多大型企业无论如何都在内部托管Java EE服务器。 到那时就可以在Java EE服务器上运行Spring应用程序了。 这种设置可以为生产中有数十甚至数百个Java应用程序的企业提供好处。 1 –迁移JEE服务器要容易得多因为应用程序*直接*使用更少的服务器API。 2 –为了减少迁移成本大多数内部客户将决定将其业务应用程序迁移到当前服务器版本。 3 – IT环境中的服务器数量减少了生产中Java版本的数量减少了本地开发环境的数量也减少了更简单的ALM解决方案–总而言之可管理的复杂性和更统一的环境。 4 –快速响应新的客户端需求如果您需要新的Spring功能则只需编译新版本的WAR / EAR文件然后将其部署到任意Java运行时。 5 –与Java EE完整堆栈相比潜在目标运行时环境的范围将更大。 这意味着您可能独立于“更多”平台。 6 –使用Spring您可以在应用程序或服务器环境中增加较小的功能避免滚雪球效应。 7 –与Java EE相比完整的创新周期更快从功能请求到生产中的使用。 8 –根据实际的实际客户项目要求对Spring进行了增强以确保其实际适用性。 9 –应用程序开发团队对应用程序开发堆栈负责并可以灵活地决定哪种API可以满足客户的需求。 在纯Java EE开发堆栈中很难实现所有这些好处其中一些解决了Java EE中的概念性问题。 一种可能的选择是模块化JEE应用服务器体系结构。 像Java SE中一样模块化是标准。 考虑发布过程即JCP也可能是有效的。 就像我之前说的我确实相信从来没有像现在这样反对JEE因为这两个选项在很多情况下都可以和谐地协同工作。 今天仍然可以同时使用Spring和Java EE就像我在其他博客文章中所解释的那样。 我相信过去的重要讨论更多地是针对我们的业务应用程序的编程模型CDI与Spring IoC以及JSF与Spring MVC。 辩论通常也是关于是否喜欢“ EJB”的情感辩论出于历史原因。 此外您的业务应用程序与基础平台服务器操作系统硬件的“真实”独立性有很多。 例如我们使用EJB作为集成技术但是业务应用程序对此一无所知。 平台独立性的关键不是使用Java EE还是使用Spring而是合理地决定在业务应用程序编程模型中直接使用哪些API。 有时最好不要使用一些application-server-lib-directory派生的目录。 参考为什么我会在2012/2013年继续通过我们的JCG合作伙伴 Niklas在新的Enterprise Java项目中使用Spring *和* Java EE。 翻译自: https://www.javacodegeeks.com/2012/05/why-i-will-continue-to-use-spring-and.html
