2

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

如果您的应用程序服务器驻留在 Windows 域中，COM+ “通过提供线程池、对象池和即时对象激活自动使您的应用程序更具可扩展性。COM+ 还通过提供事务支持来帮助保护数据的完整性，甚至如果事务跨越网络上的多个数据库” （MS 源）

因此，假设您必须在一家尚未编写可重用的 COM+ 组件的公司中从头开始构建一个大型应用程序，因此您不必依赖于该技术。

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

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

如果答案是否定的，COM+ 提供的所有服务，如分布式事务，在完全托管的环境中是否可用且易于使用？

4

2 回答 2

1

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

  1. 更容易找到开发人员（和培训）
  2. 第 3 方软件将专注于 .NET
  3. MS PSS 更适用于 .NET 开发（我知道他们并没有逐步淘汰 COM 支持，但尝试调用两个不同的问题并确定响应时间）
于 2009-01-07T15:56:45.437 回答
0

不。

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

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

于 2009-02-24T23:56:25.407 回答