您会在新的企业开发中使用 EnterpriseServices 吗？

Question

您可能已经知道，托管代码（.NET 应用程序）可以通过EnterpriseServices 使用 COM+，产生诸如分布式事务、资源池和同步“编程更简单”，因为这些解决方案是作为 COM+ 应用程序的支持基础设施提供的。

如果您的应用程序服务器位于 Windows 域中，COM+ “通过提供线程池、对象池和即时对象激活，自动使您的应用程序更具可扩展性。COM+ 还有助于保护数据的完整性通过提供事务支持，即使事务跨越网络上的多个数据库" (MS source)

因此，假设您必须在一家没有编写可重用的 COM+ 组件的公司中从头开始构建一个大型应用程序，因此您不与此相关技术。

这将是一个大系统，但您知道随着时间的推移它会变得更大。假设它类似于一个大型 ERP，分布式事务一直在进行。最后，假设系统核心将驻留在 Microsoft Windows 域中……通过 System.EnterpriseServices (ES) 采用 COM+ 成为一种选择。您必须将一些组件提供给第 3 方，您可以通过 WCF 来做到这一点。

那么，知道这项技术可用并且您的环境兼容，您会使用它吗？

如果答案是否定的，COM+ 提供的所有服务（如distributed transactions）是否都可用且易于在完全托管的环境中使用？

Answer 1

如果您还没有与 COM 结婚，我可能不会使用 EnterpriseServices。今天早上我在想一个类似的问题，如果你有使用 COM 的经验，那么 EnterpriseServices 是天赐之物。展望未来，我会选择更现代的 (.NET) 基础架构，因为

1. 更容易找到开发人员（和培训）
2. 第三方软件将专注于 .NET
3. MS PSS 更适用于 .NET 开发（我知道他们不会逐步取消对 COM 的支持，但请尝试调用两个不同的问题并确定响应时间）

Answer 2

没有。

当我们在 COM+ 中使用 .Net 时，我们遇到了无穷无尽的问题（主要是 COM+ 中无法解决的内存泄漏 - 由我们无法影响的各种 COM+ 互操作位引起）。我们更改为 WCFServices 公开业务层功能并将我们的分布式事务保持在最低限度（即事务在 WCF 服务内完成 - 您可以真正做到这一点的唯一方法）。使用内置的 .Net Transaction 东西可以处理我们处理事务所需的一切。

我会坚持使用各种 WCF 服务层来公开功能。在内部保留一层，并在与内部层通信的外部层上提供暴露的服务。它有点重，但似乎以后可以很好地扩展并提供您期望（和要求）的安全性。