Web API / 业务逻辑层架构

Question

我想就我上周继承的应用程序的结构获得一些反馈，并就如何最好地对其进行重组提出建议。尽管我并不是说我会做得更好，但我没有说出任何名字:)

这是它的本质：

Red 项目有 4 个类库：

1. UI - .NET Web 窗体。这是一个门户网站，可显示有关您的销售和工作安排的信息，以及来自其他地方的 API 的产品信息。
2. WebApiControllers - WebAPI 控制器列表。他们返回诸如 List 之类的东西（最终被序列化）。它们主要由下面另一个名为 Blue 的项目使用。
3. WebService - 一个层，其唯一工作是查询位于美国其他地方的私有 API，并返回产品信息等内容的 JSON 表示形式。
4. 域 - 据我所知，这似乎有两件事情发生。第一个是它直接调用#3（webservice）以将数据作为json返回，然后将其反序列化为相应的对象。第二个是它包含反序列化的类本身，以及用于#2 的数据传输对象。

--

Blue 项目有 1 个类库： 带有指向 Red 项目的 WebApiControllers 的 ajax 调用的 aspx 表单列表（上面的#2）

--

问题

从历史上看，红色项目将如何随着时间的推移而发展以及它的设计方式似乎存在一些混淆。由于 Red 使用 Web 表单，因此需要来自提到的私有产品 API 的大量数据。结果，我看到了以下情况：

1. 有些人从 WebApiControllers 层实例化控制器，然后直接调用他们的方法来取回对象。这发生在 Web 表单代码中。

2. 其他人直接调用 web 服务层，但这并不容易，因为每次发出请求时都需要访问或实例化请求标头、语言、用户 ID 和其他“杂乱”细节.

我在想着给webservice层做一个门面，然后通过门面指导大家访问API。唯一的问题是我将重复 WebAPIController 类库中已经完成的所有操作（因此，由于它有 30 个方法，我必须将这 30 个方法拆分到这个新层上的几个不同的外观或服务）。我不知道这是否真的是一个问题，但想把它扔在那里，看看大家的想法。然后我会告诉人们，他们不应该实例化控制器，而应该使用外观或应用程序服务层。

大家觉得呢？

谢谢！

Answer 1

外观可以工作，但正如您所提到的，建造（和维护）它可能是一项主要的工作。如果问题在于以标准方式设置 HTTP 请求，也许您可​​以提供一个实用方法来发送 HTTP 请求？比如：

public dynamic SendWebApiRequest(string url, IDictionary<string, string> parameters)

然后该方法将负责设置HttpClient、执行请求并返回结果。只是一个想法......