ps如何做ppt模板下载网站,专业装修别墅,电商运营网站设计,wordpress手机轻主题在过去的几年中#xff0c;网络技术经历了快速增长和重大变化。 我们从框架到表格布局#xff0c;再到列布局#xff0c;再到响应式布局。 从html4到xhtml和Flash到html5。 从重型服务器到富客户端。 从rpc到肥皂休息。 从sql到nosql和大数据。 从MVC到MVP等。 在以下文章中… 在过去的几年中网络技术经历了快速增长和重大变化。 我们从框架到表格布局再到列布局再到响应式布局。 从html4到xhtml和Flash到html5。 从重型服务器到富客户端。 从rpc到肥皂休息。 从sql到nosql和大数据。 从MVC到MVP等。 在以下文章中我想从我的角度描述什么已成为最新技术。 后端是REST API 每个后端应被视为REST api每个控制器应被视为另一资源。 您想分析问题领域找到您的资源并为其设计适当的路径。 它们成为您的MVC架构中的M。 首先开发一个Web应用程序然后再添加一个额外的REST api被认为是一种反模式。 如果您确实制作了REST api那么您希望自己使用它从而使前端成为第一个使用者。 此过程使您以后可以平滑地添加不同种类的客户端例如移动应用程序或什至是桌面应用程序。 这也是将您的应用程序功能集成到其他应用程序中的基础。 分离您的前端 使用带有jstl表单验证的jsp构成表单的时代正在逐渐消失。 您不想再将客户端与服务器技术混合使用。 MVC的V和C已转移到客户端您的后端仅代表模型。 您希望仅使用客户端技术html / css / js并使用REST api将前端完全分开。 GUI逻辑构建和对齐适当的html元素可以在javascript中实现。 在后端和前端之间进行信息交换的最合适的内容类型是json或xml。 富客户端和冰雹JavaScript 如今MVC模式是在客户端使用javascript及其同类框架实现的。 没有现成的功能完备的完整javascript框架但是有很多较小的库可以解决原子任务。 这不应被认为是坏的或压倒性的而是有利的。 它导致了各种各样的工具这些工具专注于彻底解决单个问题。 Backbone是基于underscore构建的流行的mvc框架这是一个js库具有强大的实用程序和出色的功能编程功能。 可以添加诸如胡子或把手之类的模板引擎 requirejs将管理模块内的依赖项。 当然不能遗漏像jQuery这样的dom操纵器。 这种趋势正导致SPA 单页应用程序使用大量的AJAJ / AJAX 并通过表示可添加书签的视图状态的html #anchors进行路由。 为您的前端实施构建过程 随着浏览器不断提高javascript性能并为html5添加越来越多的支持前端变得越来越复杂。 现在您要为前端添加一个构建过程以编译所有js和css文件。 您只想将一个缩小的js文件传送到浏览器。 除此之外我们不再破坏DRY原理的写作风格。 我们使用更少的动态样式表语言来使样式更智能更简洁并在构建过程中将其编译为CSS。 Node和rhino可能是构建前端的引擎候选者。 尽管节点要快得多但它需要在构建服务器上轻松安装。 Rhino在jvm中运行因此不需要安装。 您可以将其作为Maven依赖项添加到项目中。 移动网络与响应设计 在硬件方面移动设备变得越来越强大而对HTML5的支持也在移动浏览器中Swift增加。 HTML5可能有一天使本地移动应用程序过时。 本地存储SQL地理位置多媒体摄像头访问Web套接字图形触摸事件WebGL文件系统访问通知等等所有这些功能有一天将完全可用于移动html5 Web应用程序希望能在所有设备上正常工作。 到目前为止我们一直在为android / ios / windows mobile等开发多个应用程序这是一场经济噩梦。 移动客户端已经在Web消费中获得了可观的收益因此不再被忽视。 因此您希望使GUI 响应 从而能够缩小到较小的显示分辨率。 明智的公司甚至在考虑台式机分辨率之前就已经开始设计最小分辨率的用户界面。 这使扩展更加容易因为反之则更困难并且往往会导致痛苦的解决方法。 Bootstrap是许多可帮助您使GUI响应的库之一。 您可以使用initializr入门。 都不使用 GWT / ZK正在尝试提供一个框架该框架使仅使用Java开发现代的ajax Web应用程序成为可能。 因此他们基本上是在为前端技术构建Java包装器。 除此之外它们还提供了大量的组件。 但是……出于多种原因我想质疑他们的哲学。 它们都产生非常糟糕的html代码使您陷入元素和dom-id噩梦的境地这些噩梦变得很难甚至无法测试调试和样式化。 HTML5允许编写简短干净且可读的代码更好地组织起来。 您想自己编写html。 他们的AJAX调用不基于您需要的REST api。 如果要使用REST API则可能必须再次编写。 RPC是GWT的主要通信技术我对此确实感到担心。 但是如果愿意您仍然可以使REST api与GWT一起使用。 它们使您远离实际生产的技术。 最终微小的自定义设置可能变得很难甚至不可能。 您基本上是在放弃控制并限制您的可能性。 在许多情况下这可能会导致死胡同而死胡同是基于框架而不是技术。 GWT提供了JSNI可帮助克服此问题。 他们永远不会更新。 随着浏览器的发展日新月异必须在Java包装程序中实现新功能然后才能使用它们这会延迟您的更新时间。 我怀疑包装本机前端技术是否是个好主意而且我看不出这样做的理由。 一个专业的GWT争论可能是它正在生成优化的JS代码。 最后它们使为以前的java.awt / swing开发人员构建Web应用程序变得更加容易他们几乎不了解html / css / js。 他们现在肯定有自己的位置并且在某些情况下不是一个坏选择。 参考 “ 成为更好的开发者”博客上的JCG合作伙伴 Gregor Riegler提供的现代Web开发 。 翻译自: https://www.javacodegeeks.com/2013/07/modern-web-development.html
