Web API /业务逻辑层架构

Question

我希望得到一些关于我上周继承的应用程序结构的反馈，以及如何最好地重组它的建议。虽然我并没有说我能做得更好，但我没有说出任何名称：）

这是它的本质：

Red 项目有4个类库：

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

-

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

-

问题

历史上似乎对红色项目如何及时增长以及如何设计产生了一些困惑。由于Red使用Web表单，因此需要从提到的私有产品API中获取大量数据。结果我看到以下情况：

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

2. 其他人直接调用了webservice层，但是请求头文件，语言，用户ID和其他内容并不容易。＃34; messy＆＃34;每次发出请求时都需要访问或实例化的详细信息。

我正在考虑为webservice层建立一个外观，然后指示每个人通过外观访问API。唯一的问题是我将重复已经在WebAPIController类库中完成的所有事情（因此，由于这有30个方法，我将不得不在这个新层上的几个不同的外观或服务中拆分这30个方法）。我不知道这是不是真的有问题，但是想把它扔出去看看你们都想到了什么。然后我告诉别人他们不应该实例化控制器，而是使用Facade或应用服务层。

你们都在想什么？

谢谢！

Answer 1

门面会起作用，但正如你所提到的，建造（和维护）它可能是一项重大的苦差事。如果问题是以标准方式设置HTTP请求，也许您可​​以提供一个实用程序方法来发送HTTP请求？类似的东西：

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

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