API架构

Question

我正在设计API.我想知道我提出的是一个很好的解决方案:

我有一个存储库类型的数据层,通过将业务类转换为实体(从LLBL GEN生成,我不想直接使用实体作为我的业务对象,与数据库对话,因为我想保持它们简单并允许我交换到Entity Framework或其他一些mapper是我需要的)

我有一个WCF服务层,我正在使用它作为一种外观.它调用存储库层并将业务对象转换为DTO,并通过API服务调用将它们传递给客户端.客户端可以是ASPX网站,Silverlight应用程序,WPF应用程序,甚至是WP7应用程序.我保持运行的问题是当我想运行业务逻辑时,我必须将DTO发送回WCF服务然后再返回客户端.这对我来说似乎并不"正确".我不能把业务逻辑放在DTO中,因为这会破坏目的.但是,如果我希望在客户端上运行业务类型代码,那么在我的不同客户端中我会有大量的代码重复.

我的业务层不知道数据层,我的数据层知道业务层,我的外观层知道数据层和业务层以及DTO.这对API来说是一个糟糕的设计吗？任何人都可以给我任何建议吗？我只是通过在线阅读不同的文章了解了企业级应用程序.

谢谢!

Answer 1

层与层之间的关系

\n\n

如果我很好地理解你的设计，那么业务层不知道（=不使用）数据层，并且外观实际上通过将 DAO 转换为 DTO 来互连它们，反之亦然。

\n\n

您应该考虑一种完全不同的方法：为所有与数据相关的对象（无论是 DAO 还是 DTO）定义接口，并使用控制反转容器将业务层和数据访问层编织在一起。原因是，在您的设计中，您可能很快就会遇到无法在业务层中检索附加数据的情况。您最终会用外观来代替这种缺陷，从而执行过多的实际业务逻辑。

\n\n

如果你在业务层和底层数据层之间建立了明确的联系，同时通过精心设计的接口和 IoC 容器将它们分开，那么你可以在保持良好和简洁的内部设计的同时防止这个问题。

\n\n

DTO 的使用

\n\n

我认为您必须将 DTO 传递回应用程序的后端，这是可以的。在您的情况下，DTO 的目的是 (1) 为表示层提供信息，以及 (2) 提供一种将修改后的数据或新数据传递到后端以进行进一步处理的方法。情况 (1) 和 (2) 的 DTO 不必相同。因此，如果有意义的话，您可以仅将表示整个信息的子集的 DTO 传递到后端。

\n\n

但是，后端在处理后应返回一个新的DTO，该 DTO 不需要与输入 DTO 相同。这样，表示层可以轻松适应后端对整个对象的相关部分所做的更改。

\n\n

想象一个简单的获取/更新 API，如下所示：

\n\n

CustomerDTO GetCustomer(int customerID);\n\nCustomerDTO UpdateCustomerAddress(int customerID, AddressDTO address);\n\nCustomerDTO UpdateCustomerPrimaryContact(int customerID, PersonDTO primaryContact);\n

\n\n

您使用 ID 来标识客户并传入代表要更新的客户记录子集的 DTO（无论底层数据架构如何）。输出DTO代表整个客户，简化了表示层​​更新向用户显示的信息的任务。优点是后端不需要知道表示层实际需要哪一个客户数据子集，并且表示层可以只将真正修改的部分传递给后端。

\n\n

更新 \xe2\x80\x94 技术说明：考虑使用AutoMapper (C#)等工具来自动执行 DTO 和 DAO 之间的转换。虽然这是一个技术问题，但通常这种方法可以节省大量的手动工作，并且能够消除难以发现的错误。拥有这样的对象转换自动化有助于促进更好的设计实践，并允许您生成更专业、因此语义更准确的 DTO。

\n\n\n\n

免责声明：虽然这是一个相当普遍的问题，但对于您的问题中未涵盖的申请的更多细节，我的建议可能似乎不正确。

\n