是否将所有UI逻辑都移到客户端?


9

我们的团队最初由大多数服务器端开发人员组成,他们只具备Javascript方面的最少专业知识。在ASP.NET中,我们过去经常在代码背后或通过MVC中的控制器编写许多UI逻辑。

不久前,有2位高级客户端开发人员加入了我们的团队。他们可以在HTMl / CSS / Javascript中完成我们以前使用服务器端代码和服务器端Web控件可以做的几乎所有事情:

  • 显示/隐藏控件
  • 做验证
  • 控制AJAX刷新

因此,我开始认为,围绕我们的业务逻辑创建一个高级API可能会更有效,例如Amazon Fulfillment API:http : //docs.amazonwebservices.com/fws/latest/APIReference/,以便该客户端端开发人员将完全接管UI,而服务器端开发人员将仅专注于业务逻辑。

因此,对于订购系统,您将拥有一个高级API,例如:

OrderService.asmx

CreateOrderResponse CreateOrder(CreateOrderRequest)
AddOrderItem
AddPayment
-
SubmitPayment
-
GetOrderByID
FindOrdersByCriteria
...

可以通过JSON / REST访问API,因此很容易从客户端UI中使用。我们可以使用此API进行内部UI开发,也可以让第三方使用此API创建自己的应用程序。

随着Javascript的发展以及优秀的客户端开发人员的可用性,现在是否是摆脱代码隐藏/控制器并仅专注于开发客户端开发人员可以使用的高级API(阿拉玛)的好时机?

Answers:


6

在客户端进行验证以减轻服务器端的负担并提高应用程序的响应能力很好,但始终进行服务器端验证。可以关闭JavaScript,并且当直接使用REST API时,将永远不需要JavaScript。


是的,验证也将是域/ API的一部分。客户端会从API中提取需要验证的内容,或者我们会记录每种方法所需的内容,等等。如果客户端提交的内容仍然存在验证错误-我们将抛出异常。
Mag20 2011年

4

要注意的一件事是,复杂的UI可能需要一个额外的“ UI辅助”层来支持诸如层次结构,主/详细关系以及业务层中实际上不存在的其他UI概念之类的东西。如果没有对业务层的多次往返,通常不可能实现其中的某些功能,从而降低性能。至少,我更喜欢具有“ UI辅助”层,而不是让UI直接访问数据库。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.