精华内容
下载资源
问答
  • 来自:开源中国 协作翻译链接:oschina.net/translate/web-frameworks-conclusions原文:sitepen....当我们开始写这个系列博客的时候,我们知道 JavaScript/web 应用框架
        

    来自:开源中国 协作翻译

    链接:oschina.net/translate/web-frameworks-conclusions

    原文:sitepen.com/blog/2017/11/10/web-frameworks-conclusions/

    译者:凉凉_, wilde, 透过树叶的光等


    ?wx_fmt=png&wxfrom=5&wx_lazy=1


    是该读些评论和做一些总结的时候了。当我们开始写这个系列博客的时候,我们知道 JavaScript/web 应用框架并不太好总结。我们努力对这个不可回答的问题作出回答:我该用什么样的框架?


    在这篇文章中,我们将对这个系列中所提到的每款框架做一个总结,包括我们所认为的强项和弱项。另外,我们为你留下了一些值得思考的问题。


    我是否需要使用框架?


    如果不尝试回答这个问题就是我们的失职,这越来越成为社会上某些人的口头禅,在网络平台上的争论也已经发展到犹如不需要额外编写 API 能更简单创建 Web 应用那样的地步。就像本系列中所有的内容一样,我们的回答也大都是依据这些内容。


    虽然无框架也能正常工作,但是,这也是有代价的。那些主张无框架手写 Javascript 的人,那些通常会被我们认为是斯德哥尔摩综合症(情感上会依赖他人且容易受感动的人)的人,忘记了网络平台上有多套快速发展的 API ,至少有三种不同的技术,三种截然不同的语法。web 平台规范并确定了超过 12000 个 API,事实上浏览器中的维恩图也显示了这些巨大差距。


    如果你是一个有着深厚技术和经验的人,确实可以坦诚的不使用框架。但你团队的其他成员呢?你手下的那些人呢?或者当你的决定把你自己陷入困境的时候呢?


    这种情况下,我们将会看到一个不用框架的团队在展开冒险,最后他们会发现自己创建了一个需要自己着手维护的框架。接着就会出现寻找人才的问题,他们不需要知道框架是如何工作的,只需要寻找会调用网络平台 API 的高级技能人才或者一些自称有经验的人才,最后却发现缺少利于团队发展的技能深度和经验。


    团队应该避免虚假等价(false equivalence)的陷阱,很显然,在 web 技术的应用方面具有创新性的公司在不断提高他们的市场价值和竞争力,Google、Facebook 和 Netflix 公司都是很好的例子。但是大多数公司不是这样,他们应该承认这一点。


    Angular 2+

    ?wx_fmt=png


    有什么优势?


    Angular 2+ 的最大优势在于它的流行程度。也有人认为它和 Google 密切相关的名字,会影响团队使用它。Angular 1 的迅速流行是因为那些来自其他交互式应用程序开发环境的人会发现对于开发单页面 web 应用程序具有相似的模型-视图模式。


    通过对 Angular 1 进行现代化演变和重新构建框架的某些部分,Angular 2+ 已经真正的爆发了,大量的正式的和非正式培训机构数量都让人印象深刻,开发者有很强的市场竞争力。对于用户来说它有一套用于构建用户界面的丰富组件,这也是本系列中少有的几个框架能够做到这点。


    有什么弱点和挑战?


    我们觉得 Angular 框架着重于在单个页面应用程序中创建用户界面并没有处理构建完整的 web 应用这个更大的关注点,如果不及早确定下来,这将会导致整个项目难以维护,在实际项目中,运行时提供不属于核心框架的技术往往让人觉得不可思议,这大大降低了 TypeScript 对最终开发者的价值。


    未来将何去何从?


    Angular 5 刚刚发布,这看来是 Angular 已经成功的印证了快速发布版本的承诺,在 Google 的持续支持下,Angular 会越来越成熟。


    像许多的大型组织一样,Google 具有多重(分裂)的人格,从外表上看,Angular 团队和那些专注于浏览器标准的团队之间显得很和谐。但我们的观点是,和谐只是一层薄薄的窗户纸。Angular 团队对于 web 组件和渐进式 web 应用没有一个真正解决方案。我们认为,业界普遍认可的标准将会在 Angular 框架中会逐步实现,这将会影响到如何更好的构建 Angular 应用将成为一个中/长期的风险。


    何时选择 Angular 2+


    如果你需要在一个大型的框架内获取技术资源,框架内的技术通常很容易移植;或者你需要在框架中训练开发人员,并且还要有一定的信心,他们会在短期内获得一定的开发能力,这样的话你可以考虑 Angular 2+ 。需要注意的是 Angular1(angular.js)与 Angular2+ 是截然不同的,其中的应用、技术和经验不能直接移植到 Angular2+ 的开发中去。


    如果你的 web 应用能够很好的转化为标准的模型-视图模式,那么你也可以忽略其他直接考虑使用 Angular2+ 。


    如果你对 Google Material UX 设计模式满意,那么 Material Angular 是遵循该模式的一种快速、简单且可靠的方式。


    React + Redux


    ?wx_fmt=png

    有什么优势?


    React 和 Redux 的最大优势在于它们相对简单和专注。做一件事情并把它做好是非常困难的,但这两个库都很有效地完成了它们的目标。虽然对于某些状态容器方法可能是外部的,但大多数开发人员还是可以轻松掌握概念,并了解单向数据体系结构的好处,简化大量的用户界面应用程序。


    有什么弱点和挑战?


    React 和 Redux 最大的弱点不是它们是什么,而是它们不是什么。要构建一个功能丰富的 Web 应用程序,你需要许多功能,一旦脱离 React 和 Redux 和其他一些库的核心,你将发现一个非常分散的社区,拥有无数的解决方案和模式,不容易整合在一起。


    因此,虽然 React 和 Redux 都是非常专注的库,但缺乏经验的团队还是会很容易地生成不可维护的解决方案,而不是意识到他们所做的选择会导致性能不佳或错误。 即使有经验的开发人员也可能意识到,一个松散的架构或惯例可能会在未来困扰他们。


    假省钱是一种对自己的欺骗,组织范围内采用 React 和 Redux 将轻松降低无效率问题。 没有其他库和模式的广泛约定和标准化,标准化 React + Redux 比较于我们正在采用的 JavaScript 来编写我们的应用程序效率要高。


    未来将何去何从?


    Facebook 和 React 最近从繁琐的附加专利纠纷中抽离,他们认识到,就像其他项目一样,更广泛的社区能够提高自己的声音。 我觉得这有助于 Facebook 意识到他们还不能更好地了解我们,相信我们来引导项目。 希望这将继续贯穿项目的特点和技术方向。


    很难预测 React 和 Redux 的未来。 但是,将库集中在一起,确实会显着提高适应性,大多数React + Redux 模式都会促进一个分离的体系结构,从而可以轻松地进行重构和迭代。 两年前,大家喜欢的还是React + Flux,但整个社区很快就拥抱了Redux。 思维或模式的其他重大转变可能很容易被采纳。 这种关键能力可能会持续到未来。


    何时选择 React + Redux ?


    如果你很少需要手把手指导,并且正在寻找更好的库而不是全面的框架,那么 React + Redux 可能是正确的。 在这一过程中,你不仅需要对你的团队和组织的能力保持诚实,还要在你的初始开发过程中,以及在整个应用程序的长期维护过程中保持诚实。


    Vue.js

    ?wx_fmt=png


    有什么优势?


    渐进式构建能力是 vue.js 最大的优势,vue 有一个简洁而且合理的架构,使得它易于理解和构建。


    vue 有一个强大的充满激情人群的社区,这为 vue.js 增加了巨大的价值,使得为一个空白项目创建一个综合的解决方案变得十分容易。


    有什么弱点和挑战?


    在模型-视图应用程序和状态容器类型的应用程序之间的互相转换可能会令人感到困惑,即使没有完美包含一个模式到另一个模式的完美转换,但让人感觉希望能维持两个模式的相关性。对于那些期待 vue.js 完美解决方案,并可能导致难以维护不一致的应用程序的人来说,这至少是令人困惑的。


    一个更大的挑战是 vue.js 依赖于一个单独的人,很明显,其他的项目基本是由一个组织提供支持,但这让人感觉更加有意义,虽然它有一个强大文件的社区和许多有创新的新增项目,但是 vue 核心的开发基本落在一个人身上。


    我们很高兴看到 vue 更加容易接受新兴的标准方法,但是它的类似于 web 组件的模式,而不是真正的 web 组件,这可能是 vue 所得不偿失的地方。


    未来将何去何从?


    虽然 vue.js 有相当广泛的应用,但也很难预测在中期发展中这个势头能持续多久,它不是由一个商业组织直接支持并维护,因此,这很大程度上依赖于维护者的生存能力和继续维护下去的愿望来决定。


    它也表现出了一定程度的语言适应能力,并且随着某些模式的落伍和失宠而继续保持自身语言的现代化和时代性,目前没有迹象表明 vue.js 架构将来无法适应进一步发展。


    何时选择 Vue.js?


    如果你有一个传统的 web 应用程序,并需要一个强壮稳健的应用程序层,那么 vue.js 可能是一个很好的选择,它有清晰的模式,即使没有经验的团队也能正确或者错误的使用它。尽管 vue UX 框架没有开箱即用的功能,但在 vue.js 上也能大量持续性构建应用,这将有利于你的项目。 


    Dojo 2

    ?wx_fmt=png

    有什么优势?


    Dojo2 专注于带来更多构建在状态容器体系之上的动态组件的体验模式,填补了 react+redux 等框架的许多空白。


    Dojo2 也知道它不单单只是在自己的生态圈发展,通过包含 web 组件导入和导出功能,也意识到需要支持不同的应用实例,但它依旧提供了一个结构化和固有的框架价值,Dojo2 的核心基础仍然是专注于提供交互性。


    Dojo2 觉得它提供了大量重要的功能和解决方案,这对于构建完整的 web 应用是十分重要的,对于其他大多数框架而言这并不是重点。提供一个国际化系统和广泛的易接入性的模式也是其中之一,同时也提供一个主题系统和演进模式,用以确保不仅能为 Typescript/JavaScript 提供良好的代码开发,也能像 CSS 那样管理资源。


    Dojo2 专注于提供一个结构化和符合人体工程学的开发环境,通过使用 typescript 和其他开发模式,它试图提供安全的防护机制去引导新手开发人员,通过专注于提高框架开发效率和开发安全性,旨在让开发团队能够快速交付更好的 web 应用程序。


    有什么弱点和挑战?


    有争论的是,通过进一步延长 Dojo2 的发布时间的做法是否是在阻碍框架的发展,反观其他项目由于其资源的扩大能够继续发展和快速迭代,导致 Dojo2 目前明确的处在一个拥挤的竞争环境之中。


    这也许是一个潜在的发展机遇和挑战,同时希望能够在灵活性和交互性上而不是别的特殊理由去使用 Dojo2 。


    未来将何去何从?


    Dojo2 将是未来优秀 web 框架之一,它将继续努力为构建可扩展性的 web 应用程序提供清晰的模式和指导。随着新标准的不断出现,Dojo2 将进一步努力去在框架中实现新的标准方法,继续尝试扩大框架的开放性和交互性,创造适合更多人使用的解决方案。


    何时选择 Dojo2?


    如果你想采用一个灵活的、现代的、响应式的 web 应用程序架构,并且你需要很多智能化的默认设置,那么 Dojo2 将是一个不错的选择。不用去拼凑和构建一个管道,并且为你提供更高阶的命令模式让你可以更加专注的开发项目,更加确认它是直接为你可以直接生产开发所准备的。另外,如果你了解 typescript 的优势,Dojo2 会十分严谨的使用 typescript 来管理并提供一个稳健的开发者开发环境。


    Ember

    ?wx_fmt=png

    有什么优势?


    Ember.js可能是最固执己见的主流框架,这也是其最大的优势。它有创建Ember.js应用程序的正确方法,通常只有一种方法来创建应用程序。Ember.js更类似于一个产品或平台,在那里你会到一个供应商的长期支持和维护。Ember.js提供了对其平台的全面版本管理,升级工具以及对API升级的强大指导和工具。成熟,是对Ember.js的一个很好的总结。


    Ember.js多年来已经证明,它可以保持其框架并使其与现代标准保持一致,同时不会过早遗忘传统浏览器。


    Ember.js有一个清晰合理的架构来全面构建Web应用程序。


    有什么弱点和挑战?

    Ember.js可能是最固执己见的主流框架,这也是它最大的弱点。虽然社区是开放的并且接受投资,但是仍然需要找到一个正确的方式来摆脱下滑的趋势,这可能是具有挑战性的问题。

    拥有一个丰富的第三方社区也可能具有挑战性。由于没有开箱即用的UX组件,这很可能会让你使用第三方套件。你可能会发现,虽然这些套件并不全面,你将需要建立或寻找其他组件。由于Ember.js没有扩展,所以对如何交互和管理DOM,你会发现你有不一致的部件,而且也没有提供一个易于管理的界面。

    未来该何去何从?

    Ember.js的主要贡献者是JavaScript语言标准委员会TC39的核心参与者。在过去的几年中,Ember.js对JavaScript的方向比任何其他框架都有更直接的影响。我们的观点是,这将在未来继续受影响,并帮助促进JavaScript的特性和模式。这也意味着Ember.js将继续保持与未来标准的紧密结合的关系。

    Ember.js不可能在将来随时消失,尽管他们的创新很可能是通过与Ember.js紧密结合的其他项目来实现的,比如Glimmer,它为Ember.js应用程序提供了一个新的UI框架,该框架基于TypeScript。

    为什么我会选择Ember.js?

    如果你在框架中寻找成熟度,那么Ember.js很难出错。另外,由于Ember.js提供的内容被理解,并且有广泛的官方和官方认可的培训,以及严格的结构,找到能够建立基于Ember.js的应用程序的人才可能比其他框架更容易。也可以教大型团队如何构建应用程序,并确保整个团队的共同对话和理解。

    如果你想要对社区保持信心,并批判性地思考他们平台的变化,那么Ember.js会是一个很好的考虑因素。您可以花更少的时间跟随当前的技术趋势,并更多地关注创建应用程序。


    Aurelia

    ?wx_fmt=png

    优势在哪?


    Aurelia有很多关于构建Web应用程序的方法,结构和想法。 这个框架的编写有很多技术上的优点。


    有什么弱点和挑战?


    我们估计最大的挑战就是核心发展的动力和临界物质的缺乏。我们感觉很多的观点和概念都是我们对其他框架的批评性的想法,但是这些愿望都没有完全交付。它似乎就像是一个正在进行的工作一样,就像Dojo 2,但是它已经是一个已发布的框架。


    大部分的Aurelia是坐落在一个人的肩膀上,如果这个人的的注意力或可用性改变,那么将会带来挑战。


    未来会如何?


    对于Aurelia来说,有一个很大的机会。如果它能够实现他的愿景,他将要完整的保存这个构建Web应用程序的已有的模板,但会以更健全、更完整的方式交付。我们不知道Aurelia是否能够充分的利用这次机会。


    为什么我会选择Aurelia?


    如果您致力于Web模型视图应用程序模块,并且你和你的团队试图想把一些事做的更好,那么Aurelia会是一个选择。它就像是一个正在寻求一个更大的社区来帮助它的发展和进化的框架。


    最后的思考


    真心希望这一系列的帖子至少给了你一点思考,你应该很容易有这样的想法那就是不可能有可验证的正确决定。同时,希望你也意识到没有普遍的错误决定,你应该用一些问题和思考来武装自己,帮助你选择框架。


    一个框架仅仅是一些模式的体现,一些科技的集成,源码帮助我们更加容易去构建和维护网站应用,如果你是个体开发者,我们能提供的最好的建议是花费尽可能多的时间使用那些你认为可以为你所用的框架。


    如果你是公司的管理者或骨干领导要去做决定,请记住特点列表只是决定的一方面,有时候并不是越多越好。挑战你自己活着你的团队使用一个整体的框架,但是首先,列出对你和你的组织重要的列表,尤其是那些技术之外特点。



    展开全文
  • WebServer的优缺点

    千次阅读 2014-09-21 13:29:56
    ,WebService有什么优点和缺点,什么情况下应该用WebService?什么情况下不应该用WebService?是需要我们正确认识的。  实际上,WebService的主要目标是跨平台的可互操作性。为了达到这一目标,WebService完全基于...

            当前WebService是一个热门话题。但是,WebService究竟是什么?,WebService有什么优点和缺点,什么情况下应该用WebService?什么情况下不应该用WebService?是需要我们正确认识的。
       实际上,WebService的主要目标是跨平台的可互操作性。为了达到这一目标,WebService完全基于XML(可扩展标记语言)、XSD (XMLSchema)等独立于平台、独立于软件供应商的标准,是创建可互操作的、分布式应用程序的新平台。由此可以看出,在以下三种情况下,使用 WebService会带来极大的好处。
      优点一:跨防火墙的通信
      如果应用程序有成千上万的用户,而且分布在世界 各地,那么客户端和服务器之间的通信将是一个棘手的问题。因为客户端和服务器之间通常会有防火墙或者代理服务器。在这种情况下,使用DCOM就不是那么简 单,通常也不便于把客户端程序发布到数量如此庞大的每一个用户手中。传统的做法是,选择用浏览器作为客户端,写下一大堆ASP页面,把应用程序的中间层暴 露给最终用户。这样做的结果是开发难度大,程序很难维护。
      举个例子, 在应用程序里加入一个新页面,必须先建立好用户界面(Web页面),并在这个页面后面,包含相应商业逻辑的中间层组件,还要再建立至少一个ASP页面,用 来接受用户输入的信息,调用中间层组件,把结果格式化为HTML形式,最后还要把“结果页”送回浏览器。要是客户端代码不再如此依赖于HTML表单,客户 端的编程就简单多了。
      如果中间层组件换成WebService的话,就可以从用户界面直接调用中间层组件,从而省掉建立ASP页面的 那一步。要调用WebService,可以直接使用MicrosoftSOAPToolkit或.NET这样的SOAP客户端,也可以使用自己开发的 SOAP客户端,然后把它和应用程序连接起来。不仅缩短了开发周期,还减少了代码复杂度,并能够增强应用程序的可维护性。同时,应用程序也不再需要在每次 调用中间层组件时,都跳转到相应的“结果页”。
      从经验来看,在一个用户界面和中间层有较多交互的应用程序中,使用 WebService这种结构,可以节省花在用户界面编程上20%的开发时间。另外,这样一个由WebService组成的中间层,完全可以在应用程序集 成或其它场合下重用。最后,通过WebService把应用程序的逻辑和数据“暴露”出来,还可以让其它平台上的客户重用这些应用程序。
      优点二:应用程序集成
       企业级的应用程序开发者都知道,企业里经常都要把用不同语言写成的、在不同平台上运行的各种程序集成起来,而这种集成将花费很大的开发力量。应用程序经 常需要从运行在IBM主机上的程序中获取数据;或者把数据发送到主机或UNIX应用程序中去。即使在同一个平台上,不同软件厂商生产的各种软件也常常需要 集成起来。通过WebService,应用程序可以用标准的方法把功能和数据“暴露”出来,供其它应用程序使用。
      例如,有一个订单登 录程序,用于登录从客户来的新订单,包括客户信息、发货地址、数量、价格和付款方式等内容;还有一个订单执行程序,用于实际货物发送的管理。这两个程序来 自不同软件厂商。一份新订单进来之后,订单登录程序需要通知订单执行程序发送货物。通过在订单执行程序上面增加一层WebService,订单执行程序可 以把“AddOrder”函数“暴露”出来。这样,每当有新订单到来时,订单登录程序就可以调用这个函数来发送货物了。
      优点三:B2B的集成
      用WebService集成应用程序,可以使公司内部的商务处理更加自动化。但当交易跨越供应商和客户、突破公司的界限时会怎么样呢?跨公司的商务交易集成通常叫做B2B集成。
       WebService是B2B集成成功的关键。通过WebService,公司可以把关键的商务应用“暴露”给指定的供应商和客户。例如,把电子下单系 统和电子发票系统“暴露”出来,客户就可以以电子的方式发送订单,供应商则可以以电子的方式发送原料采购发票。当然,这并不是一个新的概念,EDI(电子 文档交换)早就是这样了。但是,WebService的实现要比EDI简单得多,而且WebService运行在Internet上,在世界任何地方都可 轻易实现,其运行成本就相对较低。不过,WebService并不像EDI那样,是文档交换或B2B集成的完整解决方案。WebService只是B2B 集成的一个关键部分,还需要许多其它的部分才能实现集成。
      用WebService来实现B2B集成的最大好处在于可以轻易实现互操作 性。只要把商务逻辑“暴露”出来,成为WebService,就可以让任何指定的合作伙伴调用这些商务逻辑,而不管他们的系统在什么平台上运行,使用什么 开发语言。这样就大大减少了花在B2B集成上的时间和成本,让许多原本无法承受EDI的中小企业也能实现B2B集成。
      优点四:软件和数据重用
      软件重用是一个很大的主题,重用的形式很多,重用的程度有大有小。最基本的形式是源代码模块或者类一级的重用,另一种形式是二进制形式的组件重用。
      当前,像表格控件或用户界面控件这样的可重用软件组件,在市场上都占有很大的份额。但这类软件的重用有一个很大的限制,就是重用仅限于代码,数据不能重用。原因在于,发布组件甚至源代码都比较容易,但要发布数据就没那么容易,除非是不会经常变化的静态数据。
       WebService在允许重用代码的同时,可以重用代码背后的数据。使用WebService,再也不必像以前那样,要先从第三方购买、安装软件组 件,再从应用程序中调用这些组件;只需要直接调用远端的WebService就可以了。举个例子,要在应用程序中确认用户输入的地址,只需把这个地址直接 发送给相应的WebService,这个WebService就会帮你查阅街道地址、城市、省区和邮政编码等信息,确认这个地址是否在相应的邮政编码区 域。WebService的提供商可以按时间或使用次数来对这项服务进行收费。这样的服务要通过组件重用来实现是不可能的,那样的话你必须下载并安装好包 含街道地址、城市、省区和邮政编码等信息的数据库,而且这个数据库还是不能实时更新的。
      另一种软件重用的情况是,把好几个应用程序的 功能集成起来。例如,要建立一个局域网上的门户站点应用,让用户既可以查询联邦快递包裹,查看股市行情,又可以管理自己的日程安排,还可以在线购买电影 票。现在Web上有很多应用程序供应商,都在其应用中实现了这些功能。一旦他们把这些功能都通过WebService“暴露”出来,就可以非常容易地把所 有这些功能都集成到你的门户站点中,为用户提供一个统一的、友好的界面。
      将来,许多应用程序都会利用WebService,把当前基 于组件的应用程序结构扩展为组件/WebService的混合结构,可以在应用程序中使用第三方的WebService提供的功能,也可以把自己的应用程 序功能通过WebService提供给别人。两种情况下,都可以重用代码和代码背后的数据。
      从以上论述可以看出,WebService在通过Web进行互操作或远程调用的时候是最有用的。不过,也有一些情况,WebService根本不能带来任何好处。
      缺点一:单机应用程序
       目前,企业和个人还使用着很多桌面应用程序。其中一些只需要与本机上的其它程序通信。在这种情况下,最好就不要用WebService,只要用本地的 API就可以了。COM非常适合于在这种情况下工作,因为它既小又快。运行在同一台服务器上的服务器软件也是这样。最好直接用COM或其它本地的API来 进行应用程序间的调用。当然WebService也能用在这些场合,但那样不仅消耗太大,而且不会带来任何好处。
      缺点二:局域网的同构应用程序
       在许多应用中,所有的程序都是用VB或VC开发的,都在Windows平台下使用COM,都运行在同一个局域网上。例如,有两个服务器应用程序需要相互 通信,或者有一个Win32或WinForm的客户程序要连接局域网上另一个服务器的程序。在这些程序里,使用DCOM会比SOAP/HTTP有效得多。 与此相类似,如果一个.NET程序要连接到局域网上的另一个.NET程序,应该使用.NETremoting。有趣的是,在.NETremoting中, 也可以指定使用SOAP/HTTP来进行WebService调用。不过最好还是直接通过TCP进行RPC调用,那样会有效得多。
    展开全文
  • web service优缺点

    千次阅读 2012-07-12 14:12:21
    与目前流行的多层开发架构(如J2EE)相比,采用Web Services技术来实现企业计算有什么优缺点? 优点: 一:数据交换 Web Service使数据交换更加方便,实现跨防火墙的通信。以一种最简单的方式实现异构系统之间的...
    与目前流行的多层开发架构(如J2EE)相比,采用Web Services技术来实现企业计算有什么优缺点?
    优点:
    一:数据交换
    Web Service使数据交换更加方便,实现跨防火墙的通信。以一种最简单的方式实现异构系统之间的互通信和数据交换,且跨平台。通过Web Service把应用程序的逻辑和数据“暴露”出来,还可以让其它平台上的客户重用这些应用程序。
    二、数据封装
    WebService使用了XML对数据封装,对于使用者而言,他能且仅能看到该对象提供的功能列表。
    三: 应用程序集成
    企业里经常都要把用不同语言写成的、在不同平台上运行的各种程序集成起来,而这种集成将花费很大的开发力量。通过Web Service,应用程序可以用标准的方法把功能和数据“暴露”出来,供其它应用程序使用。
    四:低成本
    在实际项目开发中的开发成本是最低的,无论从软件开发人员的培训和web service产品的购买都是廉价的
    缺点:
    一:单机应用程序。
    二:使用xml封装,在网络上必须传输一些多余的数据。
    三:企业计算不可能单独采用WebService,WebService只是作为补充。
    四:缺少安全性
    展开全文
  •   也就是我们常说的web层。它负责接收客户端请求,向客户端响应结果,通常客户端使用http协议请求web 层,web 需要接收 http 请求,完成 http 响应。   表现层包括展示层和控制层:控制层负责接收请

    服务端三层架构

    我们的开发架构一般都是基于两种形式,一种是 C/S 架构,也就是客户端/服务器,另一种是 B/S 架构,也就是浏览器服务器。在 JavaEE(企业) 开发中,几乎全都是基于 B/S 架构的开发。那么在 B/S 架构中,系统标准的三层架构包括:表现层、业务层、持久层。
    表现层:
      也就是我们常说的web层。它负责接收客户端请求,向客户端响应结果,通常客户端使用http协议请求web 层,web 需要接收 http 请求,完成 http 响应。
      表现层包括展示层和控制层:控制层负责接收请求,展示层负责结果的展示。
      表现层的设计一般都使用 MVC 模型。(MVC 是表现层的设计模型,和其他层没有关系
    业务层:
      也就是我们常说的 service 层。它负责业务逻辑处理,和我们开发项目的需求息息相关。web 层依赖业务层,但是业务层不依赖 web 层。
    持久层:
      也就是我们是常说的 dao 层。负责数据持久化,包括数据层即数据库和数据访问层,持久层就是和数据库交互,对数据库表进行曾删改查的。

    MVC模型

    MVC 全名是 Model View Controller,是模型(model)-视图(view)-控制器(controller)的缩写
    Model(模型):
      通常指的就是我们的数据模型。作用一般情况下用于封装数据。
    View(视图):
      通常指的就是我们的 jsp 或者 html。作用一般就是展示数据的。
      通常视图是依据模型数据创建的。
    Controller(控制器):
      是应用程序中处理用户交互的部分。作用一般就是处理程序逻辑的。
      当前台传参服务端在接参数的时候也会对类型校验,如果校验失败,由控制器把错误页面展示给使用者,如果成功控制器负责把数据填充到模型,然后调用业务层执行业务层代码。

    SpringMVC 是什么

    SpringMVC 是一种基于 Java 的实现 MVC 设计模型的请求驱动类型的轻量级 Web 框架,属于
    Spring FrameWork的后续产品,从而在使用 Spring 进行 WEB 开发时,可以选择使用 Spring的 Spring MVC 框架或集成其他 MVC 开发框架,如 Struts1(现在一般不用),Struts2 等。

    SpringMVC 的优势

    (1)强大的 JSP 标签库,使 JSP 编写更容易。支持各种视图技术,而不仅仅局限于JSP;
    (2)和 Spring 其他框架无缝集成,是其它 Web 框架所不具备的。
    (3)清晰的角色分配:前端控制器(dispatcherServlet) , 请求到处理器映射(handlerMapping), 处理器适配器(HandlerAdapter), 视图解析器(ViewResolver)。
    (4) 支持各种请求资源的映射策略。并且支持RESTful 编程风格的请求。

    SpringMVC 的缺点

    (1) Spring与MVC 的Servlet API 耦合,难以脱离容器独立运行
    (2) 太过于细分,开发效率低
    (3) 原理不容易理解。

    展开全文
  • 正在从事Web前端工作的小伙伴们一定不会对Web前端框架陌生,那么这么多的框架各有什么优缺点呢?为了帮助小伙伴们提高工作效率,今天为大家整理了不同框架的优缺点分别是什么?下面来和我一起来看一看吧! 一、 Web...
  • 原文作者:康熙终码一生 1.背景 ...前后端分离已成为互联网项目开发的业界标准使用方式,通过nginx+tomcat的方式(也可以中间加一个nodejs)有效的进行解耦,并且前后端分离会为以后的大型分布式架构、...Web...
  • Nginx 和 Apache 各有什么优缺点

    千次阅读 2018-04-11 17:44:07
    nginx 相对 apache 的优点:轻量级,同样起web 服务,比apache 占用更少的内存及资源抗并发,nginx 处理请求是异步非阻塞的,而apache 则是阻塞型的,在高并发下nginx 能保持低资源低消耗高性能高度模块化的设计,...
  • Web:6 大主流 Web 框架优缺点对比之Aurelia Aurelia 1.有什么优势? Aurelia有很多关于构建Web应用程序的方法,结构和想法。 这个框架的编写有很多技术上的优点。 2.有什么弱点和挑战? 我们估计最大的挑战...
  • Web:6 大主流 Web 框架优缺点对比之Vue

    千次阅读 2018-05-23 12:56:24
    Web:6 大主流 Web 框架优缺点对比之Vue.js Vue.js 1.有什么优势? 渐进式构建能力是 vue.js 最大的优势,vue 有一个简洁而且合理的架构,使得它易于理解和构建。 vue 有一个强大的充满激情人群的社区,这为 ...
  • 轻量级,同样起web服务,比apache占用更少的内存及资源 抗并发,nginx处理请求是异步非阻塞的,而apache则是阻塞型的,在高并发下nginx能保持 低资源低消耗高性能 高度模块化的设计,编写模块相对简单 社区活跃...
  • Web服务器:一般指像nginx,apache这类的服务器,他们一般只能解析静态资源。 应用服务器:一般指像tomcat,jetty,resin这类的服务器可以解析动态资源也可以解析静态资源,但解析静态资源的能力没有web服务器好。 ...
  • 一、前戏 前后端分离已成为互联网项目开发的业界标准使用方式,通过nginx+tomcat的方式(也可以中间加一个nodejs)有效的进行解耦,并且前后端分离会为以后的大型分布式架构、弹性计算...Web服务器:一般指像nginx,a
  • 轻量级,同样起web 服务,比apache 占用更少的内存及资源 抗并发,nginx 处理请求是异步非阻塞的,而apache 则是阻塞型的,在高并发下nginx 能保持低资源低消耗高性能 高度模块化的设计,编写模块相对简单 社区活跃...
  • Web:6 大主流 Web 框架优缺点对比之Ember Ember 1.有什么优势? Ember.js可能是最固执己见的主流框架,这也是其最大的优势。它有创建Ember.js应用程序的正确方法,通常只有一种方法来创建应用程序。Ember.js更...
  • 一、前端 前后端分离已成为互联网项目开发的业界标准使用方式,通过nginx+tomcat的方式(也可以中间加一个nodejs)有效的进行解耦,并且前后端分离会为以后的大型分布式架构、弹性计算...Web服务器:一般指像nginx,a
  • jsp页面放在web-inf和webroot下的优缺点CSDN问题:jsp放在webroot目录下 这样就可以让用户直接访问,jsp放在web-inf目录下就必须要通过请求才能访问。...还有放在webroot和放在web-inf目录下都各有什么明显的优缺点
  • Web:6 大主流 Web 框架优缺点对比之DoJo 2 Dojo 2 1.有什么优势? Dojo2 专注于带来更多构建在状态容器体系之上的动态组件的体验模式,填补了 react+redux 等框架的许多空白。 Dojo2 也知道它不单单只是在自己...
  • [转]j2ee struts,spring,hebernate框架各自有什么优缺点.struts是一个比较老的框架了,从出现到现在已经快7年了,它出现之前web开发规范还处于比较混乱的状态,正是它的出现把web开发带入了一个新的时代,在当时说...
  • 1、nginx相对于apache的优点: 轻量级,同样起web 服务,比apache占用更少的内存及资源抗并发,nginx 处理请求是异步非阻塞的,而apache 则是阻塞型的,在高并发下nginx 能保持低资源低消耗高性能高度模块化的设计,...
  • 6 大主流 Web 框架优缺点对比之Angular 2+ Angular 2+ 1.有什么优势? Angular 2+ 的最大优势在于它的流行程度。也有人认为它和 Google 密切相关的名字,会影响团队使用它。Angular 1 的迅速流行是因为那些来自...
  • Web:6 大主流 Web 框架优缺点对比之React + Redux React + Redux 1.有什么优势? React 和 Redux 的最大优势在于它们相对简单和专注。做一件事情并把它做好是非常困难的,但这两个库都很有效地完成了它们的目标...
  • 大家好,我想问一下,在工作站上装服务器版的操作系统有什么优缺点,以及把一个web服务放在工作站上有什么限制? 谢谢了
  • 模块化开发的优缺点: 优点: 可维护性高 架构清晰,灵活开发 降低程序耦合性 方便模块功能调试、升级以及模块间的组合分解 缺点: 损耗性能 系统分层,调用链长 模块间通信发送消息很消耗性能 ...
  • 这个商业逻辑必须由Web应用程序的开发者以及JavaBean或EJB的形式提供 View:Struts提供了action form创建form bean,用于在controller和view间传输数据。此外,Struts提供了自定义JSP标签库,辅助开发者用jsp创建...
  • Django:Python 界最全能的 web 开发框架,battery-include 各种功能完备,可维护性和开发速度一级棒。常人说 Django 慢,其实主要慢在 Django ORM 与数据库的交互上,所以是否选用 Django,取决于项目对数据库...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 518
精华内容 207
关键字:

web有什么优缺点