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

本文关键字：自动生成 对象 WS NET SOAP | 更新日期: 2023-09-27 18:31:13

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

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

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

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

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

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

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

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

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

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

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

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

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

存储 库：

  • 如果您需要它长寿且可扩展

代：

  • 使用命名空间和类命名，以明确类已生成并将被覆盖。
  • 创建部分类或扩展生成的类以提高灵活性
T4

工具箱（如果使用 T4

）
  • 模块化 T4
  • 保留自定义代码
相关文章：