高效构建 Web 服务的架构？ [关闭]答案

【问题标题】：Architectures for efficiently building Web Services? [closed]高效构建 Web 服务的架构？ [关闭]
【发布时间】：2012-12-16 07:18:39
【问题描述】：

我最近在做一个 Web 服务项目，发现我选择的架构效率极低。

我以一种非常程序化的方式编写了这篇文章，带有一点 OOP 和使用 Python 的标准异常处理的提示。基本上，它将按程序逐步检查数据，验证预期数据的存在，根据正则表达式验证数据，根据数据库验证一些数据，执行一些特定逻辑，检查错误，然后最终返回响应。提及所有数据均使用 JSON 交换可能会有所帮助。

我试图回顾代码，找到任何重复的异常，并将它们的处理推到逻辑链的顶部。这并不像我希望的那样容易，而且实际上花费了更多时间。它还使我的代码更容易出现错误，因为它的单元可测试性更低且更难阅读。

我注意到这种用于处理用户数据的程序代码范式很容易被 Web 开发所迷惑。例如，在 PHP 中处理表单时，可能会对数据运行一系列连续的 isset() 和 !empty() 方法。我对这种编码风格的问题是我觉得我花费了大量时间来为错误事件编码，并且很难为这个特定目的概括和重用代码。

各种框架通过使用表单类（例如 Django）提供了很好的解决方法。但是，我注意到虽然您通过减少验证逻辑的重复来节省时间，但您仍然需要为每个预期输入“构建”一个表单。在处理软件即服务时，可能有数百个 API 方法需要您编写代码。 OOP 在这里提供了一个好处，但有时客户可能会设置一个奇怪的要求，从而消除所获得的任何效率。

Web 应用程序可以从遵循 MVC 等范例/架构中受益匪浅。以我个人的经验，MVC（以及使用其原理的框架）并不能很好地解决这类问题。我考虑过使用函数式语言，但还没有尝试过。

是否有非常适合开发自定义 SASS 或 Web 服务项目的特定语言、架构/范式、约定甚至示例框架？

【问题讨论】：

您能否更具体地说明您真正的“棘手部分”是什么？是用户输入的复杂性和性质吗？是您的“业务逻辑”的复杂性和性质吗？您是否有大量无法处理的边缘情况？
hymloth，我相信我的问题在于用户输入的复杂性和过多的边缘情况。并不是说这项任务是不可能的；但在开发方面效率非常低。有一次，我有大约 90% 的代码只是处理边缘情况，而我的实际逻辑通常是每个“API 方法”的几行代码。许多框架向开发人员灌输了一种约定，这使开发更快、更流畅，但在构建极其自定义的代码时会让你发疯。由于没有写一个新的框架，我还没有想出任何解决这个问题的解决方案。

标签： web-services web-applications architecture

【解决方案1】：

作为从事大量此类工作的人，我会说您的 OOP 和 PHP 问题的部分原因是因为最初 PHP 不是 OOP 语言。 OOP 后来被添加到该语言中。因此，当您查看代码示例时，它们通常会有一种程序化的感觉。

近年来，我对 Spring (Java) 或 WCF (C#) 最满意。这两种语言都是强类型的 OO 语言。从概念的角度来看，这导致了一个适用于我的项目的范例。以下是概述：

端点（REST 或 WSDL）——类似于 MVC 中的视图
服务——这些服务提供端点并根据需要协调 DAO。围绕您的业务逻辑组织这些内容
数据访问对象——将数据转换为本机对象，反之亦然。围绕您的数据源组织这些。
模型/API -- 支持应用程序并自动为您的服务提供文档的原生对象。

希望有帮助

【讨论】：

谢谢，门把手。实际上，我在这些项目中都没有使用 PHP，但我可以感谢您对 PHP 及其非 OOP 背景的评论。这些天，我通常是一名 Python 编码员。我确实同意 REST 非常好，尽管在这个项目中不是一个选项。我从来没有研究过 WSDL，所以我会检查一下。我注意到我的经验和你的经验之间的一个区别是，我不只是提供对数据的访问层。在您提到的几点中，您似乎将数据放在首位。但是，在我处理过的项目中，如果有意义的话，重点是方法。
不管我的个人需求如何，我相信你给出的答案会对其他人有所帮助，并提供一些非常有用的常见约定或架构。 +1