用Java编写UI 100％并通过API提供数据是个好主意吗？

我的主要工作是制作HTML应用程序。我的意思是，内部使用CRUD类型的应用程序，其中包含许多可编辑的Gridview，文本框，下拉菜单等。我们目前正在使用ASP.NET Web窗体，虽然确实可以完成工作，但是性能通常很差，而且通常您必须跳篮球才能获得所需的东西。吊在天花板上的铁环会燃烧。

所以我想知道将所有UI移到JavaScript端是否是一个好主意。开发一组强大的可重用控件，这些控件专门针对我们的需求量身定制，并且仅与服务器交换数据。是的，我喜欢“控件”（又名“小部件”）范例，它非常适合此类应用程序。因此，在服务器端，我们仍将具有与当前ASPX标记类似的基本布局，但是之后将仅发送给客户端一次，而Javascript部分将负责所有后续的UI更新。

问题是我以前从未做过此事，也从未见过任何人这样做过，所以我不知道会有什么问题。我特别担心：

• 性能依然。基准测试表明，当AJAX更新后浏览器尝试重新呈现大部分页面时，当前主要延迟在客户端。ASP.NET webforms生成的标记为“ web”一词赋予了新的含义，丰富的Devexpress控件在此之上添加了自己的Javascript复杂性层。但是，重新计算Javascript方面的所有必要更改然后仅更新需要更新的内容会更快吗？请注意，我所谈论的表单具有多个可编辑的gridview，许多文本框，许多下拉列表，每个下拉列表中都包含了半百万个可过滤项，等等。
• 易于发展。现在将有更多的Javascript，并且可能与页面的HTML标记混合。那或某种新的视图引擎将必须被生产。Javascript的Intellisense也比C＃代码差很多，并且由于Javascript的动态特性，不能期望它会变得更好。编码实践可以使它有所改善，但幅度不大。另外，我们的大多数开发人员主要是C＃开发人员，因此会有一些学习过程和最初的错误。
• 安全性。许多安全检查将必须进行两次（服务器端和UI端），并且数据处理服务器端将必须包含更多安全检查。当前，如果您在服务器端将文本框设置为只读，则可以依赖于其值在客户端往返过程中是否保持不变。该框架已经具有足够的代码来确保（通过视图状态加密）。使用纯数据方法会变得更加困难，因为您必须手动检查所有内容。另一方面，可能会更容易发现安全漏洞，因为您只需要担心数据。

总而言之，这将解决我们的问题，还是使它们变得更糟？有没有人尝试过，结果如何？是否有任何框架可以帮助这种工作（不包括jQuery和道德上的对等）？

Linkedin在其移动网站上执行此操作（请参见http://engineering.linkedin.com/nodejs/blazing-fast-nodejs-10-performance-tips-linkedin-mobile第4部分），显然，这对于他们来说非常有益性能观点。

但是，出于各种原因，我建议您避免这样做。

首先是可维护性：由于C＃/ ASP.net是服务器端框架，因此与客户端无关，而Javascript则不是（即使使用jQuery这样的框架，您也不会获得100％的跨浏览器兼容性） ，而不是面向未来的）。我要说的是，验证静态类型的应用程序的功能比动态应用程序还容易，这对于构建大型站点绝对是必须考虑的事情。

第二个问题是，您将很难找到能够（并愿意）构建运行整个网站所需的复杂程度的纯JavaScript应用程序的人（相比之下，相对容易找到）。 NET程序员）。这可能不是您直接关心的问题，但是从长远角度来看当然是需要考虑的事情。

第三个问题是客户兼容性。如果您要建立面向公众的网站，请记住，网络中有相当一部分仍未启用JS（出于各种原因），因此，您需要绝对确保不会排除很大一部分通过切换到JS驱动的网站来确定用户群。

至于您的子弹问题：

• 我不会太担心安全性方面的问题，没有理由为什么当您需要安全性时您不能混合使用范式并进行一些服务器端处理（要在返回HTML的地方放置一些视图渲染代码） ，则没有理由不能仅在需要时触发AJAX调用）。

• 在我看来，易于开发并不是真正的问题，在我看来，有非常好的JS开发工具可用，不要因为习惯了而将自己装进VisualStudio中！（例如，尝试使用JetBrains WebStorm）。

• JS视图引擎的性能在大多数情况下绝对是不错的（再次以我的经验），我每天都会大量使用它们。我的建议是避免使用更笨重的框架，例如敲门（Knockout.js）等，而转而使用乔恩·雷西格（Jon Resig）的微型模板引擎。这样，您就可以以确信快速而可靠的方式插入支持代码。

如果我是你，我会做的是真正地研究这种转换背后的原因。很有可能您只是没有有效地利用.NET并需要完善您的游戏，WebForms并不是现成的特别慢的框架，因此也许您正在使用的某些第三方库正在减慢您的渲染速度。

尝试使用负载测试和性能分析工具对应用程序进行性能分析，并在将大量时间和精力投入到更根本的解决方案之前，先了解瓶颈所在，您可能会惊讶于发现造成您缓慢的罪魁祸首！

如果要这样做，请使用ExtJS，不要重新发明轮子。但是要做好准备，这意味着彻底改变范式。您的HTML技能几乎已过时。到处都是AJAX，服务器主要提供AJAX API。您将比以往编写更多的javascript，因此最好确保您确实适合javascript。

我所在的团队决定在2008年末迁移到ExtJS。那时，我们有一个20万行的PHP应用程序，遇到前端问题。我们的情况比您的情况差很多，因为我们有一个非常糟糕的手动表单控件框架，并且我们大量使用iframe加载页面的各个部分（可视化架构可以追溯到2005年，并且团队并不知道早期的ajax）。无论如何，我们都必须重构代码，因此这使得决定将代码库主要重新构建为主要客户端方面变得更加容易。

今天的应用程序有300.000行，其中60.000行是extjs代码，大约3/4的功能已迁移到ExtJS。extjs代码都是单页应用程序，但仍将一些旧式表单嵌入到iframe中。我们首先移植了导航容器，然后逐步迁移了不同的功能区域。通过这种方法，我们成功地将extjs迁移整合到常规功能开发过程中，而不会减慢我们的工作速度。

• 性能

  事实证明，ExtJS代码比传统代码要快得多。当然，旧代码在性能方面确实很差，但即使如此，我们对结果还是满意的。UI代码都是静态javascript，因此缓存非常好（我们处于将其放入CDN的计划阶段）。该服务器不参与前端渲染，从而减少了那里的工作量。它还有助于ExtJS在UI的生命周期中提供很多控制（惰性渲染，轻松卸载不可见的UI元素）。通常，一旦代码被引导（按需加载架构），则屏幕的大部分加载时间都将花费在Web服务调用中以获取数据。ExtJS网格的速度非常快，尤其是在使用缓冲视图在滚动中呈现可见行时。

• 易于发展

  老实说，这是一个混蛋。ExtJS是DSL，不是传统意义上的Web开发。我们的开发人员花了很长时间才真正了解到该框架的API，而且我认为在其他客户端框架上的曲线也不会那么陡峭。团队中的每个人都必须是“高级” JavaScript开发人员（根据经验，克罗克福德的书中不应包含任何秘密）。我们遇到了新开发人员自举的问题，因为客户端的专业知识没有您想象的那么广泛，而extjs的专业知识几乎为零（在我们所在地的比利时）。

  另一方面，一旦您掌握了速度，开发人员的经验就会非常好。ExtJS非常强大，因此，如果您处于困境中，则可以快速启动惊人的屏幕。在IDE方面，我们使用PHPStorm，我发现它具有足够的ExtJS代码功能。

• 安全

  安全性是执行客户端UI的主要原因之一。原因很简单：减少攻击面。我们的ExtJS代码使用的Web服务API的受攻击面比服务器端UI层小得多。OWASP的ASVS指定在使用服务器之前，应验证服务器上所有输入的正确性。在Web服务体系结构中，何时以及如何进行输入验证是显而易见且容易的。我还发现，在客户端UI架构中推断安全性更容易。我们仍然在XSS问题上苦苦挣扎，因为您并没有摆脱编码到HTML的束缚，但是总的来说，与以前的代码库相比，我们在安全性方面要好得多。ExtJS使轻松进行表单域的服务器端验证成为可能，因此不必为编写两次代码而苦恼。

如果您负担不起不支持无脚本用户的费用，并且搜索引擎不关心您，那么可以，这是一种完全可行的方法。以下是优缺点的简要介绍：

优点：

• 一切都集中在一处（javascript）
• 您可以从服务器而不是标记加载数据，如果操作正确，可以节省大量带宽
• 更容易获得响应式应用程序（网络延迟仍然存在，但是对用户输入的初始响应会更快）
• Web服务器不需要呈现任何HTML或扩展任何模板（即，将处理工作从服务器移到了客户端）

缺点：

• 一切都需要使用javascript（可能是或不是问题）
• 关键逻辑需要在服务器上复制
• 状态需要在客户端和服务器上维护，并在两者之间进行同步
• 安全性可能更难解决（考虑恶意用户如何操纵客户端代码中的任何内容）
• 您公开了代码库的大部分内容（无法从外部看到在服务器上运行的代码）

我个人认为，如果您走这条路，ASP.NET UpdatePanels并不是正确的方法。它们非常适合部分废除现有的Web应用程序，但是它们仍然通过AJAX发送HTML，并且以这种方式管理状态可能非常麻烦。最好一直处理，只提供一个静态HTML文档，然后使用javascript模板库进行HTML渲染。服务器根本不提供任何动态HTML，而是由客户端对服务器进行业务逻辑级别的调用并接收原始数据。

是的，你可以，但是..

您需要确保您具有正常的“降级”，以便应用程序的关键部分仍可以在没有Javascript的情况下正常工作。

这就是我构建大多数应用程序“ HIJAX”样式的方式。

我的网站仍处于起步阶段，但到目前为止，对我来说100％js ui很好。前端存在的唯一服务器逻辑是模型映射和Ajax URL。服务器根本不了解ui，对我而言这很容易维护。如果您有兴趣，可以签出用ExtJS http://coffeedig.com/coffee/编写的我的网站。我的站点实际上没有任何安全问题，但是客户端通过简单的验证可以帮助普通用户。我知道恶意用户实际上可以将任何ajax发送到服务器，因此所有“安全”逻辑都在服务器上完成。

我认为对您来说最大的问题是，您将完全颠覆团队的习惯，学习曲线将非常陡峭。我认为最好的方法是尝试一些js框架，并尝试通过编写一些简单的屏幕来获得它的感觉。