在API和应用程序之间共享对象的模式

我对我的Web应用程序的设计有严重的怀疑。

我想将业务逻辑与接口分开，所以我制作了一个Web API，用于处理对数据库的所有请求。

它是具有实体框架，工作单元和通用存储库模式的ASP.NET Web API。到目前为止，一切都很好。

问题

我需要帮助的地方是，我找不到在API和应用程序之间共享对象的有效方法。

我不想直接序列化实体对象，我认为这将是一个坏习惯，因为如果实体模型发生更改，我最终可能会无缘无故地序列化大型对象。

现在如何实施

因为我的接口是C＃中的ASP.NET Web应用程序，而我的API是C＃中的API，所以我创建了一个公共库，其中定义了我想在它们之间共享的所有类。

我知道当我开发一个Android应用程序时该解决方案将不起作用，我将不得不再次用Java创建类，但这不是我最大的问题。

问题是我感觉自己一直在转换对象。

例

这是我的工作流程示例：

我从包含所有对象和表单数据注释的模型开始，然后用户将模型发布到控制器。

在控制器中，我必须将此模型转换为我的公共库中的类，然后将该对象发送到我的API。

然后，我的API中的控制器捕获了该调用，并将该对象转换为实体对象以更新数据库。

所以我有3节课

1. 视图的模型以及用于验证的所有数据注释（客户端）
2. 共享对象的公共库类（DLL）
3. 实体类（API）

我感觉自己做错了什么。还有更优雅的东西吗？我想确保在这个项目变得太大之前，我有一个很好的解决方案。

我知道您似乎一直在不断地在数据库对象，数据传输对象，带有验证逻辑的客户端对象之间来回转换对象，但我会说不，您没有做错任何事情。

这些对象中的每一个都可以代表相同的信息单元，但是它们的职责却非常不同。数据库对象是您与数据库的通信接口，应保留在数据库层中，因为它可能有也可能没有不同的数据库元数据注释和/或其中的有关数据库实现的不必要的详细信息。

您的数据传输对象是与API使用方的通信接口。它们应尽可能干净，以方便从不同语言/平台中消费。根据您希望支持的API使用者，这可能会对它们的外观和行为施加某些限制。

具有验证逻辑的客户端对象实际上不是您的API项目的一部分，而是您的使用者项目的一部分。在这种情况下，它们不能与数据传输对象相同，因为您要在其上添加额外的客户端特定的逻辑（在这种情况下为验证属性），而服务器对此一无所知（也不应该知道！）。将这些对象算作您的API的一部分，因为它们实际上不是。它们是特定于用户的应用程序，某些使用您的API的应用程序甚至可能实际上甚至不需要创建这些对象，并且也可以仅在您的数据传输对象上生存。例如，如果您不需要验证，则不需要额外的与数据传输对象完全相同的对象层。

在我看来，这三种对象类型中的每一种似乎都很好地映射到一个职责，即干净的编码和良好的实践。可悲的是，干净的代码和良好的做法有时意味着您正在编写大量额外的代码，并且“只是因为”而跳过了额外的麻烦。而且在编码时，可能很难理解它给您带来的价值-但是，一旦您发布应用程序并开始支持它或为下一个版本添加新功能，您可能会开始意识到花了一些时间来首先适当地分离这些问题。（更不用说你

我也讨厌这样在不同对象类型之间编写转换代码，但是我的解决方案通常是以下之一：

• 使用可以为您完成大部分对象转换工作的库-例如，如果您使用C＃，则可以使用出色的AutoMapper库（http://automapper.org/）。我相信还有许多其他类似的库，但是AutoMapper是迄今为止我所见过的最强大的库。
• 如果找不到库来帮助您进行对象转换，请编写一组实用程序方法以在它们之间进行转换。这可能很烂，但是从长远来看，这是值得的，第一次需要转换内容时，请编写转换方法-不要等待。