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

Question

您可能已经知道，托管代码（.NET应用程序）可以通过EnterpriseServices使用COM +，从而产生分布式事务，资源池等问题和同步“更简单的编程”因为COM +提供了解决方案作为应用程序的支持基础结构。

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

所以，你说你必须在一个没有编写COM +组件的公司中从头开始构建一个大型应用程序，你可以重复使用它，所以你不绑定到那个技术

这将是一个很大的系统，但你知道随着时间的推移它会变得更大。让我们说它就像一个大型ERP，分布式交易一直在进行。最后，假设系统核心将驻留在Microsoft Windows域中......通过System.EnterpriseServices（ES）可以选择采用COM +。您必须为第三方提供一些组件，您可以通过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服务层来公开功能。保持一个内部层，并在与内部层通信的外部层上提供公开的服务。它有点沉重，但似乎可以很好地扩展，并提供你期望（和要求）的安全性。