您会在新的企业开发中使用 EnterpriseServices 吗？
您可能已经知道，托管代码（.NET 应用程序）可以通过 EnterpriseServices，使诸如分布式事务、资源池和同步等问题“更容易编程”，因为解决方案是作为通过 COM+ 支持应用程序的基础结构。
如果您的应用程序服务器驻留在 Windows 域中，COM+“通过提供线程池、对象池和即时对象激活，自动使您的应用程序更具可扩展性。COM+ 还通过提供事务来帮助保护数据的完整性”支持，即使事务跨越网络上的多个数据库” （MS 源）
因此，假设您必须在一家尚未编写可重用的 COM+ 组件的公司中从头开始构建一个大型应用程序，因此您 >不与该技术相关。
这将是一个很大的系统，但您知道随着时间的推移它可能会变得更大。 假设它就像一个大型 ERP，分布式事务一直在进行。 最后，假设系统核心将驻留在 Microsoft Windows 域中...使得通过 System.EnterpriseServices (ES) 采用 COM+ 成为一种选择。 您必须向第三方提供一些组件，您可以通过 WCF 来实现。
那么，知道这项技术可用并且您的环境兼容，您会使用它吗？
如果答案是否定的，那么 COM+ 是否提供了所有服务，例如 分布式事务，在完全托管的环境中可用且易于使用？
As you may already know, managed code (.NET apps) can make use of COM+ through EnterpriseServices, making issues like distributed transactions, resource pooling and synchronization "simpler to program" because the solutions are provided as a supporting infrastructure to the application by COM+.
If your application servers reside in a Windows domain, COM+ "automatically makes your applications more scalable by providing thread pooling, object pooling, and just-in-time object activation. COM+ also helps protect the integrity of your data by providing transaction support, even if a transaction spans multiple databases over a network" (MS source)
So, say you have to build a big application from scratch in a company that has not written COM+ components which you can reuse, so you are not tied to that technology.
This will be a big system, but you know it could get much bigger with time. Let's say it's something like a big ERP, with distributed transactions going on all the time. Finally, let's say that the system core will reside in a Microsoft Windows domain... making the adoption of COM+ through System.EnterpriseServices (ES) a choice. You will have to make some components available to 3rd parties, and you can do so via WCF.
So, knowing this technology is available and that your environment is compatible, would you use it?
If the answer is no, are all the services COM+ offers, like distributed transactions, available and easy to use in a fully managed environment?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您还没有与 COM 结婚，我可能不会使用 EnterpriseServices。 今天早上我正在考虑类似的问题，如果您有使用 COM 的经验，那么 EnterpriseServices 就是天赐之物。 展望未来，我会选择更现代的 (.NET) 基础设施，因为
I probably wouldn't use EnterpriseServices if you're not already married to COM. I was thinking about a similar problem this morning, and if you have experience with COM, then EnterpriseServices is a godsend. Moving forward I would choose more modern (.NET) infrastructure because
当我们在 COM+ 中使用 .Net 时，我们遇到了无穷无尽
的问题（主要是 COM+ 中无法解决的内存泄漏 - 由我们无法影响的各种 COM+ 互操作位引起）。 我们更改为公开业务层功能的 WCFServices，并将分布式事务保持在最低限度（即事务在 WCF 服务内完成 - 这是您真正可以做到的唯一方法）。 使用内置的 .Net Transaction 东西可以处理我们处理事务所需的一切。
我会坚持使用各种 WCF 服务层来公开功能。 将一层保留在内部，并在与内部层通信的外部层上提供公开的服务。 它有点重，但似乎可以很好地扩展并提供您期望（和需要）的安全性。
No.
We had no end of issues (mainly unresolvable memory leaks in COM+ - caused by various COM+ interop bits we couldn't affect) when we went with .Net in COM+. We changed to WCFServices exposing business layer functionality and kept our distributed transactions to a minimum (i.e. The transaction is complete inside the WCF service - The only way you can do it really). Using the built in .Net Transaction stuff handles everything we needed to handle transactionwise.
I would stick with various WCF service layers to expose functionality. Keep one layer internal and provide exposed services on an external layer that communicates with the internal layer. It's a bit heavy but seems to scale well later and provides the security you'd expect (and require).