您是否会在新企业开发中使用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服务层来公开功能。保持内部一层，并在与内部层通信的外部层上提供公开的服务。这有点沉重，但似乎稍后会扩展，并提供您所期望（和要求）的安全性。