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

Question

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

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

因此，假设您必须从头开始构建一个大型应用程序，而没有编写的COM+组件，您可以重用这些组件，所以您是而不是与该技术相关的。

这将是一个很大的系统，但你知道，随着时间的推移，它会变得更大。比方说，这有点像一个大型的ERP，分布式事务一直在进行。最后，假设系统核心位于Microsoft域中.使通过COM+ (ES)采用System.EnterpriseServices成为一种选择。你将不得不使一些组件提供给第三方，你可以通过WCF这样做。

因此，知道这种技术是可用的，并且您的环境是兼容的，您会使用它吗？

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

Answer 1

如果你还没有和COM结婚，我可能不会使用EnterpriseServices。今天早上我也在想一个类似的问题，如果你有使用COM的经验，那么EnterpriseServices就是天赐之物。向前看，我会选择更现代化的(.NET)基础设施，因为

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

Answer 2

不是的。

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

我会坚持使用各种WCF服务层来公开功能。将一个层保持在内部，并在与内部层通信的外部层上提供公开的服务。它有点重，但似乎很晚才扩展，并提供了您期望的安全性(以及所需的安全性)。