JavaScript中的业务逻辑。胖客户vs瘦客户

您可以创建可重用的javascript模块,这样就不存在在几个不同的富uis中恢复逻辑的内在障碍。然而,正如已经指出的,您可能最终会在JavaScript和您在服务器上使用的任何东西(Java、PHP…)之间进行复制——在验证的情况下,这是由于复制导致性能用户体验和复杂性之间的折衷。

我可以想象这样的场景,您将选择复制不仅仅是验证。考虑计算总订单值:我们真的想为此进行服务器端往返吗?排序一个列表-我们倾向于在JavaScript中这样做,但是我们排序可以得到有趣的、专门的比较器功能?划定边界可能很困难,计算折扣和销售税?

最后,这是一个判断的召唤,然后是对后果的仔细理解。如果你重复逻辑,那么你能设计出一个确保一致性的测试策略吗?对于低容量系统,您可能倾向于支持更多的服务器交互和更少的重复,但对于更大或更苛刻的用户群,您可能会做出不同的决定。

永远不应该信任客户。因此,在客户端使用JavaScript进行的任何验证都只能提高用户的便利性和可用性。以后您总是需要验证服务器上的传入数据,以确保没有人注入数据等。

从性能的角度来看,在JavaScript中实现验证逻辑很方便,因为用户不必等待服务器调用,但仍然需要验证发送到服务器的所有数据。

如果你不这样做,你最终会被恶意的人腐蚀你的后台系统。

一种方法是使用某种类型的Web服务/Web方法访问,让您的javascript对这些方法进行Ajax调用,对业务逻辑进行验证,然后将返回发送回前端。

现在前端可以与服务器聊天,但是您可以轻松地将该业务逻辑验证与同一域中的其他应用程序共享。这种方法的第二个好处是,所有业务逻辑和验证都在服务器上,并且不会以恶意人员可以轻松查看或操作代码的方式公开。

祝你好运,希望能有所帮助。

“2013年的夫妇(可能有意见)笔记:

Web应用程序的开发不应与任何其他应用程序不同。

采用任何2层以上的应用程序(任何普通的客户机-服务器模型都可以);在客户机或服务器上处理事情是否有意义?

性能注意事项

您必须考虑处理能力、网络延迟、网络带宽、内存和存储限制。根据应用程序的不同,您可以选择不同的权衡。

胖客户机通常允许您在客户机上处理更多的内容,卸载服务器,序列化更高效的消息有效负载,并最小化往返,所有这些都以处理能力、内存效率和可能的存储空间为代价。

安全注意事项

安全性是暂时的,无论使用何种模型,每一方(不仅仅是服务器)都必须在某种程度上验证并可能清理从另一方接收到的数据。对于许多Web应用程序,这意味着用业务逻辑验证实体,但并非总是如此。这取决于数据是什么,以及谁有权控制它(并不总是服务器)。

由于Web浏览器已经验证了大量信息,因此客户端考虑的因素更少,但不应被忘记(尤其是在制作XHR或使用WebSockets的客户机中,这种客户机的手持设备更少)。

有时,这意味着实际上服务器和客户机都将验证相同的数据。没关系。如果您在两侧开发软件,您可以将验证代码提取到客户机和服务器都使用的模块中(就像传统软件包中的所有这些“公共”模块一样)。因为在Web环境中,您对语言的选择在客户端是有限的,所以您可能不得不妥协。也就是说,您可以在服务器上执行javascript,或者使用emscripten(也可以参见amd.js)等工具将多种语言编译为javascript,甚至可以在不确定的将来使用nacl/pnacl等工具运行本机代码。

结论

我发现将Web应用程序客户机视为“立即安装”、“零配置”和“持续更新”客户机有助于理解。我们不在Web上使用这个术语,因为这些属性通常是基于Web的经典软件固有的,但它们不适用于经典的本地软件。同样,在开发本机软件时,我们不使用“单页应用程序”这样的术语,因为在需要使用经典软件切换到新屏幕时,不需要重新启动整个应用程序。

拥抱这种融合,保持开放的心态;来自不同社区的人们在未来几年将从彼此身上学到很多东西。

应该使用javascript来丰富用户在GUI中的体验,但是您的站点/webapp在没有它的情况下仍然可以工作。

发送到服务器的参数可以由用户操作。如果您依靠javascript来验证或创建这些值,那么基本上就是要求用户尝试做一些淘气的事情。(他们会的)

用于验证的javascript很好,它将为正常使用应用程序的用户减少对服务器的请求量。但这仍然需要丰富他们的经验。您仍然需要验证L33T H@X0R中1%的服务器端,这些用户将试图创建问题。

在过去的几年里,我做了很多Ajax工作,我的看法是:

• 将业务逻辑放在客户机中以增强更重要的服务器端验证。我在一些金融机构工作过 他们总是有很好的安全保障,因为这是做深入。客户端验证、服务器端验证、框架安全性等,但它们总是在应用程序的每个部分中都有。他们从未假设任何东西都是安全的,他们构建自己的内部网应用程序,就好像它们是互联网应用程序一样。
• 其他业务逻辑也可以放进去,但始终保持瘦客户机的想法。我将业务逻辑放在客户机中的另一个主要原因是为了性能。

例如,有一次我有一个最上面的下拉列表,它在页面上检测到了它下面的五个其他控件。我意识到,最上面的控件发出了一个调用,并以级联方式控制所有后续控件上的数据显示,而不是对每个控件进行服务器端跳闸。其他控件之间使用相同的数据进行交互操作,除非更改了最上面的下拉列表。所以我创建了一个缓存/处理数据的管理器,性能非常好!大多数用户交互都是基于最初的下拉选择,这是一种80-20的使用规则。大多数时候,他们只是做了一个选择,得到了他们想要的。

• 在客户机中使用表示逻辑。我的意思是,如果你在下拉列表上进行排序,你可以通过一个属性在一个GUI小部件中进行排序,那么无论如何都要进行排序。当我在MVP(ModelView Presenter)范式中与GWT一起工作时,您永远不会将任何业务逻辑放在视图中,但您可以将表示逻辑放在视图中。这不是商业逻辑,而是与另一个很好地联系在一起。

业务逻辑应该尽可能与消费者无关。如果设计得当,客户机和服务器代码应该能够以可重用的方式使用业务逻辑(假设客户机和服务器都可以使用JavaScript)。

从客户机(浏览器等)使用业务逻辑可以防止对服务器的不必要的攻击,前提是恶意用户不会绕过您的UI来攻击您的端点。然后,您的服务器可以使用这一相同的业务逻辑作为最后一道防线。

此外,如果设计得当,您可以扩展业务逻辑以包含更复杂的工作流逻辑,这些逻辑需要在事务上下文中运行,等等;通常情况下,通过客户机很难实现。

有很多 design patterns 它可以帮助您设计可重用的业务逻辑。

还有一些微框架可用,例如 peasy-js ,帮助您快速创建易于重用、可扩展、可维护和可测试的业务逻辑。