用什么做网站最好,网页游戏推荐排行,云服务器gpu租用,网页制作个人主页模板spring javaee在Java社区中#xff0c;Spring vs JavaEE是一个永无止境的争论。 在这样的辩论中#xff0c;人们组成一个团体#xff0c;由两个传播者#xff0c;建筑师和一个平台的核心粉丝组成#xff0c;并且不断进行辩论。 参与辩论的人可能是负责平台选择的架构师。 … spring javaee 在Java社区中Spring vs JavaEE是一个永无止境的争论。 在这样的辩论中人们组成一个团体由两个传播者建筑师和一个平台的核心粉丝组成并且不断进行辩论。 参与辩论的人可能是负责平台选择的架构师。 但是开发人员会如何看待这次Spring vs JavaEE辩论 我是同时使用Spring和JavaEE的Java开发人员并且不属于Spring或JavaEE粉丝俱乐部。 在这里我想就这个史诗般的Spring vs JavaEE辩论分享自己的想法。 1.商业有时是政治方面 在许多组织中技术选择可能并不完全取决于开发人员的选择。 更具体地说如果您在所谓的巨型企业组织中工作那么很有可能会有架构团队来决定在项目中使用哪种平台/语言/框架/库。 除此之外大型企业在选择技术平台时还考虑以下方面 平台/语言/框架/库的成熟度 商业支持 许可费用等 作为开发人员我几乎不会影响上述任何方面的决策过程尤其是当我是离岸开发中心的开发人员时。 所以我不用太担心这些事情。 2.如果您真的很擅长Spring / JavaEE那么学习另一个也不应该很困难 当有人说我是JavaEE专家但我听不懂Spring时我总是感到惊讶。 JavaEE和Spring都在相同的核心APIServletJPAJMSBeanValidation等上工作不同之处在于谁将Spring或AppServer粘合在一起。 即使对于诸如依赖注入Spring DICDIRESTJAX-RSSpringMVC等事物有一些不同的API它们的外观和行为也非常相似。 也许有人可以说CDI比Spring DI更安全。 在以下情况下Spring和CDI的行为不一样吗 如果只有一个Spring / CDI Bean则使用Autowired或Inject进行注入可以正常工作 当存在多个Spring或CDI bean实现时注入失败并抛出错误“找到了多个可以注入的合格bean”注入失败。 使用Produces或Bean注释方法将自定义对象提供为Bean提供程序 只要它们的行为类似我不在乎它们是以类型安全的方式实现还是在其内部实现中使用基于String的映射。 怎样才能成为Spring的专家却不懂JavaEE反之亦然 Spring专家学习JavaEE需要多少时间 3.对“ Average Joe开发人员”更友好 我认为到目前为止很多人应该已经意识到一项技术的成功可能并不完全取决于其优点还取决于开发人员的采用。 要实现的最重要的事情是“并非每个软件开发人员都是摇滚明星开发人员。 与热情的技术忍者相比普通的joe开发者更多”。 因此为了使人们适应任何框架它应该对“ Average Joe Developer”友好。 我认为Spring通过提供更多工具例如SpringBoot用户指南等来做得很好。SpringSecuritySpring IntegrationSpring XDSpring Social很好地满足了现代业务需求。 还请考虑一下Spring提供的各种模板这些模板使操作变得简单而无需担心样板代码。 通过引入JBossForgeWildfly Swarm等快速入门JavaEE也表现出色。 我遇到了一些基于JavaEE的框架例如Picketlink该框架可以解决安全性要求但是我觉得它比应该的要复杂得多。 我要传达的观点是“您可以使用Spring进行JavaEE中的几乎所有工作”。 区别在于这让普通的joe开发人员可以立即使用。 4.没有上下文的arguments脚论点 每当Spring vs JavaEE辩论出现时人们就会组成两个小组并不断进行辩论。 不幸的是辩论集中在一些无用或过时的观点上。 XML重 JavaEE爱好者首先开始说Spring是XML的重头戏我讨厌XML等等。 如果您仍在使用早于2.5版的Spring并假设它仍然基于XML那么我的朋友应该醒来并转到http://spring.io EJB不好或JSF不好 Spring迷们像EJB 2.x或JSF 1.x一样猛扑EJB和JSF。 如果他们真的关注EJB 3.x和JSF 2.x那么他们根本不会争论。 不要凭着6年的EJB2.x经验来判断EJB3.x。 重或轻 我对“重量”的解释是基于运行时的足迹。 据我所知当您将托管bean部署到JavaEE容器中时容器将代理它并注入所有企业服务事务安全性等如果是Spring它将由Spring AOP完成。 我没有任何度量标准可以说哪个是比较重的Container Proxy或SpringAOP Proxy但是我想可能没有太大的区别。 有些人将战争档案的大小视为其“重量”。 在那种情况下将JavaEE AppServer war大小与带有126个jars的SpringApp进行比较看看哪一个重量轻:-) JavaEE是基于标准的 拜托了伙计们 供应商锁定 我认为选择一个不会让您坚持某个特定供应商的平台是好的。 但是仅基于迁移到其他实现的能力来选择选项是不正确的。 一年中从一台服务器切换到另一台服务器多少次 选择不与供应商锁定您的平台是“很不错的选择”但这不是选择平台的主要因素。 我们不需要外部库 这称为“为争辩而争辩”。 向我展示任何没有依赖关系的真实应用程序。 如果您说我要开发自己的日志记录库我要编写自己的HTTP客户端我要开发自己的通用工具那么您需要寻找一些没有“重新发明”的懒惰的架构师/开发人员。所有轮子的疾病。 5.不要看着人群说“你们都是白痴因为您使用X所以应该迁移到Y”。 这是我在许多社区站点上观察到的常见模式尤其是在Reddit上。 只需发布与JavaEE vs Spring相关的任何东西就会有两个小组像其他一样抨击另一个小组因为另一个小组没有使用他们喜欢的平台。 想一分钟。 如果说Spring不好为什么会有很多人使用它并喜欢它。 如果JavaEE不好为什么会有很多人从Spring切换到JavaEE。 每个平台上都有很多好东西。 尊重他人选择他们选择的任何选项。 如果可能的话请问他们为什么选择彼此的理由并了解您是否错过任何事情。 只是说“你们都是不使用我喜欢的选项的白痴”并不能使他们使用您喜欢的技术。 实际上这触发了人们的想法提出了您最喜欢的平台烂点的清单。 如果您确实希望他们切换到自己喜欢的平台请通过代码示例显示原因。 向他们展示使用您喜欢的平台和示例应用程序开发应用程序有多么容易。 写更多有关常见问题及其解决方法的文章。 将“ Average Joe Developer”安装到您喜欢的平台上。 作为一个热情的Java开发人员我阅读了Spring vs JavaEE的讨论希望可能有一些我不知道的事情例如“在哪个领域比另一个领域更好”。 但是我发现70的讨论都是关于la脚的争论这对我来说不是很有趣。 我希望Spring和JavaEE阵营之间的战斗越来越多并使他们的平台比其他平台更好。 归根结底无论谁赢得了辩论最终开发人员都将拥有更强大的平台。 翻译自: https://www.javacodegeeks.com/2015/06/a-developers-perspective-on-spring-vs-javaee.htmlspring javaee
