用 JavaScript 在客户端实现业务逻辑是个好主意吗？
应该有什么样的逻辑？验证逻辑？和GUI有关吗？
如果相同的逻辑想在另一个应用程序中使用（暴露的）在 JavaScript 中实现它意味着你不能重用该逻辑，你会怎么做。
另一方面，在服务器端拥有所有逻辑意味着对服务器的更多请求。
你怎么看？
【问题讨论】：
标签： javascript client-side server-side
永远不应该信任客户。因此，您在客户端使用 JavaScript 进行的任何验证只能是为了提高用户的便利性和可用性。您总是必须稍后在您的服务器上验证传入的数据，以确保没有人注入数据等。
【讨论】：
您可以创建可重用的 Javascript 模块，这样在几个不同的富用户界面中恢复逻辑就没有内在障碍。但是，正如已经指出的那样，您最终可能会在 JavaScript 和您在服务器上使用的任何内容（Java、PHP ...）之间出现重复 - 在验证的情况下，这是提供性能之间的权衡重复导致的用户体验和复杂性。
我可以想象您会选择复制更多内容的场景，而不仅仅是验证。考虑计算总订单价值：我们真的要为此进行服务器端往返吗？对列表进行排序——我们倾向于在 JavaScript 中愉快地做到这一点，但是我们排序可以获得有趣的、专门的比较器函数吗？划定界限可能相当棘手，要计算折扣和销售税？
最终，这是一个判断电话，然后是对后果的仔细理解。如果你重复逻辑，那么你能设计一个确保一致性的测试策略吗？对于低容量系统，您可能倾向于支持更多的服务器交互和更少的重复，但您可能会为更大或更苛刻的用户群做出不同的决定。
【讨论】：
从性能的角度来看，在 javascript 中实现验证逻辑很方便，因为用户不必等待服务器调用，但您仍然需要验证发送到服务器的所有数据。
如果你不这样做，你最终会被恶意的人破坏你的后台系统。
【讨论】：
尝试做您正在寻找的事情的一种方法是使用某种类型的 Web 服务/Web 方法访问，并让您的 javascript 对方法进行 ajax 调用，对业务逻辑进行验证，然后发送返回回到前端。
现在前端将与服务器聊天，但您可以轻松地与同一域内的其他应用程序共享该业务逻辑验证。这种方法的第二个好处是所有业务逻辑和验证都在服务器上，不会以恶意人员可以轻松查看或操作代码的方式暴露。
祝你好运，希望这对一些人有所帮助。
【讨论】：
'2013 年的情侣（可能有意见）笔记：
Web 应用程序的开发方式不应与任何其他应用程序不同。
采用任何 2 层以上的应用程序（任何普通的客户端-服务器模型都可以）；在客户端或服务器上处理事情有意义吗？
性能考虑
您必须考虑处理能力、网络延迟、网络带宽、内存和存储限制。根据应用程序，您可以选择不同的权衡取舍。
胖客户端通常允许您在客户端处理更多内容并卸载服务器，序列化更有效的消息有效负载，并最大限度地减少往返，所有这些都以处理能力、内存效率和可能的存储空间为代价。
安全注意事项
安全性是暂时的，无论使用何种模型，每一方（不仅仅是服务器）都必须在某种程度上验证并可能在一定程度上清理从另一方接收到的数据。对于许多 Web 应用程序，这意味着使用业务逻辑验证实体，但并非总是如此。这取决于数据是什么，以及谁拥有对它的权限（并不总是服务器）。
由于网络浏览器已经验证了大量信息，客户端的考虑较少，但不应忘记（尤其是在制作 XHR 或使用 WebSockets 的客户端中，手持较少）。
有时，这意味着服务器和客户端确实会验证相同的数据。还行吧。如果您在双方都开发软件，您可能会将您的验证代码提取到客户端和服务器都使用的模块（就像传统软件包中的所有这些“通用”模块一样）。由于您选择的语言在 Web 环境中的客户端受到限制，因此您可能不得不妥协。话虽如此，您可以在服务器上执行 Javascript，或者使用 Emscripten（另见 amd.js）之类的东西将许多语言编译成 Javascript，甚至使用 NaCl/PNaCl 之类的东西在不确定的未来运行本机代码。
结论
我发现将 Web 应用程序客户端视为“立即安装”、“零配置”和“持续更新”客户端会有所帮助。我们不会将这个术语用于 Web，因为这些属性始终是经典的基于 Web 的软件所固有的，但它们不适用于经典的本地软件。同样，我们在开发原生软件时不会使用“单页应用程序”之类的术语，因为当我们需要使用经典软件切换到新屏幕时，我们从来不需要重新启动整个应用程序。
拥抱融合，保持开放的心态；未来几年，来自不同社区的人们将相互学习很多东西。
【讨论】：
应该使用 JavaScript 来丰富用户在 GUI 中的体验，但您的网站/web 应用程序在没有它的情况下仍然可以工作。
发送到服务器的参数可以由用户操作。如果您依赖 Javascript 来验证或创建这些值，那么您基本上是在要求您的用户尝试做一些顽皮的事情。 （他们会的）
验证的Javascript很好，它会减少正常使用该应用程序的用户对您服务器的请求量。但这仍然属于丰富他们的经验。您仍然需要验证服务器端是否有 1% 的 l33t h@x0rs 会尝试制造问题。
【讨论】：
过去几年我做了很多 AJAX 工作，我的看法是这样的：
例如，有一次我有一个最顶部的下拉菜单，它影响了页面上它下面的五个其他控件。我意识到最顶层的控件进行了一次调用并以级联方式控制所有后续控件上的数据显示，而不是为每个控件进行服务器端访问。除非最上面的下拉列表被更改，否则其他控件在它们之间使用相同的数据进行互操作。所以我创建了一个缓存/处理数据的管理器，性能非常好！大多数用户交互都基于最初的下拉选择，一种 80-20 的使用规则。大多数时候，他们只是做了一个选择，就得到了他们想要的。
【讨论】：
业务逻辑应尽可能与消费者无关。如果设计得当，您的客户端和服务器代码应该能够以可重用的方式使用您的业务逻辑（假设客户端和服务器都可以使用 javascript）。
假设恶意用户没有绕过您的 UI 来攻击您的端点，那么从客户端（浏览器等）使用您的业务逻辑可以防止对服务器的不必要攻击。然后，您的服务器可以使用相同的业务逻辑作为您的最后一道防线。
此外，如果设计得当，您可以扩展业务逻辑以包含更复杂的工作流逻辑，这些逻辑需要良好执行、在事务上下文中运行等；通常情况下，很难通过客户端进行处理。
您可以依靠许多design patterns 来帮助您设计可重用的业务逻辑。
还有可用的微框架，例如 peasy-js，可帮助您快速创建易于重用、可扩展、可维护和可测试的业务逻辑。
【讨论】：