JavaScript中的业务逻辑。胖客户端与瘦客户端
使用JavaScript在客户端实现业务逻辑是一个好主意吗？JavaScript中的业务逻辑。胖客户端与瘦客户端
应该有什么样的逻辑？验证逻辑？与GUI相关？
如果想要在另一个应用程序中使用相同的逻辑（公开），则在JavaScript中实现它将意味着您不能重用该逻辑。
另一方面，服务器端的所有逻辑意味着对服务器的更多请求。
您认为如何？
您可以创建可重用的Javascript模块，因此在几个不同的丰富的uis中没有内在的障碍来重演逻辑。然而，正如已经指出的那样，您可能最终会在JavaScript和您在服务器上使用的任何内容（Java，PHP ...）之间重复 - 在验证的情况下，这是在给予高性能用户体验和复制造成的复杂性。
我可以想象你会选择复制不仅仅是验证的场景。考虑计算总订单价值：我们真的想为此做一个服务器端往返吗？对列表进行排序 - 我们倾向于在JavaScript中高兴地做到这一点，但我们排序可以获得有趣的专用比较函数吗？绘制边界可能相当棘手，计算折扣和销售税？
最后，这是一个判断呼吁，然后仔细了解后果。如果你重复逻辑，那么你能制定一个确保一致性的测试策略吗？对于低容量系统，您可能倾向于支持更多的服务器交互和更少的重复，但您可能会为更大或更高要求的用户群做出不同的决定。
从性能角度来看，在javascript中实现验证逻辑很方便，因为用户不必等待服务器调用，但仍需验证发送到服务器的所有数据。
如果你不这样做，最终会有恶意的人破坏你的后台系统。
永远不要信任客户。因此，您使用JavaScript在客户端进行的任何验证只能提高用户的便利性和可用性。您以后必须始终验证服务器上的传入数据，以确保没有人注入数据等。
JavaScript应该用于丰富用户在GUI中的体验，但是您的站点/ webapp仍然可以在没有它的情况下运行。
发送到您的服务器的参数可以由用户操纵。如果你依靠Javascript来验证或创建这些值，你基本上会要求你的用户尝试去做一些调皮的事情。 （他们会）
验证的Javascript是好的，它会减少正常使用应用程序的用户对服务器的请求量。但这仍然在丰富他们的经验。您仍然需要验证服务器端是否会尝试创建问题的l33t h @ x0rs的1％。
尝试执行所寻找的一种方法是使用某种类型的Web服务/ Web方法接口，并让JavaScript对方法执行ajax调用，对业务逻辑进行验证，然后发送返回到前端。
现在前端将与服务器聊天，但您可以轻松地与同一域中的其他应用程序共享该业务逻辑验证。这种方法的第二个好处是，所有的业务逻辑和验证都在服务器上，而不是以恶意代码轻松查看或操纵代码的方式公开。
祝你好运，并希望这有助于一些。
我已经做了很多AJAX的工作在过去的几年里，我的对其采取的是：
- 把业务逻辑在客户端，以增加更重要的服务器端验证。我曾在一些金融机构工作过，他们一直都有非常好的安全性，因为这是深入的。客户端验证，服务器端验证，框架安全等等，但是他们总是在应用程序的每个部分都有它。他们从来没有假设任何事情都是安全的，他们构建了内联网应用程序，就好像它们是互联网应用程序一样
- 其他业务逻辑也可以放入，但始终保持瘦客户机的想法。我将业务逻辑放在客户端的另一个主要原因是性能。
例如，我有一个最上面的下拉菜单，它在页面下面检测到其他五个控件。我没有为每个控件做一次服务器端跳闸，而是意识到最顶层的控件进行了一次调用，并以层叠的方式控制所有后续控件的数据显示。除非最上面的下拉列表发生了变化，否则其他控件会在相同的数据之间进行相互操作。所以我创建了一个缓存/处理数据的管理器，而且性能非常好！大多数用户交互都是基于最初的下拉选择，这是一种80-20的使用规则。大多数时候他们只做了一个选择并得到了他们想要的东西。
- 在客户端使用演示逻辑。通过这个我的意思是，如果你有一个下拉列表，你可以通过一个属性在GUI Widget中进行排序，那么通过一切手段去做。当我在MVP（模型视图展示器）范式中使用GWT时，您绝不会在视图中放置任何业务逻辑，但您可以将表示逻辑放在该视图中。这不是商业逻辑的束缚，而是与其他商业关系密切。
“情侣（可能opiniated）从2013年指出：
的Web应用程序不应该比任何其他应用程序来开发不同。
取任何2+层应用程序（任何普通的客户端 - 服务器模型都可以）;在客户端或服务器上处理事情有意义吗？
性能考虑
你必须要考虑到的处理能力，网络延迟，网络带宽，内存和存储的限制。取决于应用程序，您可以选择不同的权衡。
胖客户端通常会允许您在客户端上处理更多内容并卸载服务器，序列化更高效的消息负载并最小化往返次数，所有这些都是以处理能力，内存效率和可能的存储空间为代价的。
安全考虑
安全性是短暂的，无论所使用的模式，每一方（不仅仅是服务器）将始终需要验证和消毒可能从另一组接受一定程度的数据。对于许多Web应用程序，这意味着使用业务逻辑来验证实体，但并非总是如此。这取决于数据是什么，谁拥有权限（并且它并不总是服务器）。由于网络浏览器已经验证了很多信息，因此客户端的注意事项较少，但不应该被遗忘（尤其是在使XHR或使用WebSockets的客户端中，手持较少）。
有时，这意味着服务器和客户端确实会验证相同的数据。还行吧。如果您开发双方的软件，您可以将验证代码提取到客户端和服务器使用的模块（如传统软件包中的所有这些“常见”模块）。由于您在网络环境中的客户端语言选择有限，因此您可能必须妥协。话虽如此，你可以在服务器上执行Javascript，或者使用诸如Emscripten（也可参见amd.js）之类的语言编译多种语言，甚至可以在不确定的将来使用NaCl/PNaCl等运行本机代码。
结论
我发现它有助于思考的Web应用程序客户端为“立即安装”，“零的conf”和“不断更新”的客户。我们不使用这个术语来说明网络，因为这些属性一直是传统的基于网络的软件固有的，但它们不适用于传统的本地软件。同样，在开发本地软件时，我们不使用“单页应用程序”这样的术语，因为当我们需要使用传统软件切换到新屏幕时，从不需要重新启动整个应用程序。
拥抱融合，保持开放的心态;来自不同社区的人们将在未来几年相互学习。
业务逻辑应尽可能与消费者无关。如果设计得当，您的客户端和服务器代码应该能够以可重用的方式使用您的业务逻辑（假设客户端和服务器都可以使用JavaScript）。
从客户端（浏览器等）消费您的业务逻辑可以防止对服务器的不必要命中，假设恶意用户不绕过您的UI来击中您的端点。然后，您的服务器可以使用相同的业务逻辑作为最后一道防线。此外，如果设计得当，您可以扩展业务逻辑以包含更复杂的工作流程逻辑，这些逻辑需要在事务处理环境中运行良好，运行良好等。一般情况下，通过客户端很难促成的事情。
有很多design patterns，你可以依靠帮助你设计可重用的业务逻辑。
还有可用的微框架，如peasy-js，可帮助您快速创建易于重复使用，可扩展，可维护和可测试的业务逻辑。
这意味着您应该在**（客户端x服务器）端都保留验证规则。 – rsenna 2010-11-10 15:32:17