在 .NET 中使用 SOAP WS 时使用自动生成的类/对象？

Question

在当前的项目中，我必须开发一个 .NET 客户端应用程序，该应用程序使用少量 SOAP Web 服务与外部软件进行通信。

幸运的是，.NET 使得使用 SOAP WS 变得非常容易，因为它在添加服务引用时会生成所有必需的对象。

另一方面，在玩了一段时间这个自动生成的类之后，我不确定是直接在业务逻辑中使用它们更好，还是应该将它们映射到我自己的模型中（例如，使用类似存储库模式的东西）。

制图的优点：
- 业务逻辑和数据访问分离（WS 可以改变）
- 调用 WS 的中心点（可以验证响应并进行适当的错误处理）
- 有时 WS 类型使用起来很麻烦（例如 WebService1.TypeA 与 WebService2.TypeA 不兼容）。
- 生成的类不能/不应自定义。
- ...

映射的缺点：
一些使用的 WSDL 具有复杂的结构和大量的嵌套类型。如果将它们映射到我自己的模型，我必须复制许多类和属性。这就是我对这个解决方案感到担忧的原因。

简而言之我不确定将 Web 服务类复制到我自己的命名空间以及存储库或外观模式的实现是否是正确的方法，或者只是破坏架构。

是否有任何最佳做法或类似做法？

Answer 1

在我 20 多年的经验中，如果项目的生命周期不确定或可能是短暂的，那么添加存储库/服务层可能会过大。还有一个额外的性能问题，但是如果正确完成，SOAP 本身将比对象映射层更多地成为瓶颈。此外，裸对象应用程序不会从关注点分离中受益。

话虽如此，如果您现在连接到一个 SOAP 端点，您很可能正在开发一个企业应用程序，该应用程序应该被构建为存在几年并随着时间的推移而增强。也就是说，旨在满足不断增长的需求。因此，就您的利弊而言，根据我的经验，这取决于时间投资的回报。根据您在此处发布的信息，额外的努力将是有益的。

如果操作得当，Generation 可以成为一个很好的工具。为了类似的目的，我在我的项目中进行了大量的 T4 生成。就最佳实践而言，我将我的类生成到一个“生成的”子命名空间中并扩展它们。这样我就可以扩展功能和结构，而不必担心它们被覆盖。在生成的类中，我将所有内容标记为部分和虚拟，以便我有继承之外的选项。一次完成所有操作可能有点矫枉过正，但需要考虑。利用部分类可能是修改和扩展生成的类的另一种方式。
您甚至可以生成扩展/部分类。我使用 T4Toolbox 生成外部文件并使用“PreserveExistingFile”来防止文件被覆盖。 T4Toolbox（如果您还没有使用它）提供了一种很好的模块化方式来管理您的生成，甚至生成到其他项目中。

即使您不添加存储库层，我也会鼓励您应用 Composite 和 Façade 模式的概念来简化与外部服务的交互。

因此，回顾一下我的经验中的最佳实践：

存储库：

• 如果您需要它长期存在且可扩展

世代：

• 使用命名空间和类命名，清楚地表明该类已生成并将被覆盖。
• 创建部分类或扩展生成的类以获得灵活性

T4Toolbox 如果使用 T4

• 模块化 T4
• 保留自定义代码