使用ACE也有1年的时间了，从初见ACE时的惊艳，到积极的学习ACE并大胆的将其引入到工程中，再到现在的复杂心情，有些话我真是不吐不快。
我是在windows下做开发的，由于所做的工程涉及到很多界面操作，所以仍然采用了MFC作为开发的基础类库。也许是ACE与MFC天生不合吧，一开始便遇到了问题——内存泄漏！为了这个问题，我在ACE的网站上、yahoo的两个ACE讨论组和当时的小飞驴论坛进行了仔细的搜索，没有发现有人遇到相同的问题。于是我斗胆将这个问题贴到了CSDN上面。很快，就得到了结果——并不是如何解决这个问题，而是很多人对这个问题本身的怀疑——很多人认为ACE是经历了工业强度的考验的，是不可能存在内存泄漏的，就算有，也应该是我自己的问题，而不是ACE的问题。也有一些朋友提出了一些可行的建议，但是没有一个能够真正的彻底解决我所遇到的问题。我不知道ACE网站上列出的成功使用了ACE的项目里面有几个是将ACE和MFC混用的，反正我是一直都无法解决这个问题。不过因为到最后导致的泄漏相当轻微，所以在没有办法的情况下，这个问题也只好暂时搁置了。
随着工程越做越大，需要维护的代码也越来越多，我不得不开始考虑模块划分的问题。其实从一开始，我就已经充分的考虑了模块化的问题。dll我是不打算采用了（不想陷入dll hell中去），从windows平台上看来，除开.net，对大型工程模块化的最佳手段，应该算是COM组件技术了。但是鉴于当时整个开发团队对COM技术的掌握程度，以及COM技术本身的复杂性和某些缺陷，我也放弃了在项目初期引入COM技术进行模块划分的想法。于是我们采用简单的namespace对源代码进行模块划分。这样直接导致了项目后期的编译速度巨慢和源代码的难以维护和控制。为了解决这个问题，我开始尝试从关键模块开始，由核心团队去建立相应的COM组件。从整个工程来说，最核心的东西，在于网络层。看起来要将整个网络层的代码封装到一个COM组件中去，似乎并不是那么困难。于是我们开始信心十足的进行代码移植工作，但是很快的，我们又遇到了一个难以逾越的障碍。出于某些方面的考虑，从一开始我们在网络层所写的所有代码，都没有涉及到MFC，而是用标准C++写成，这也为我们进行代码移植工作提供了理由：我们可以将这些代码与MFC彻底隔离开来，我们可以使用ATL编写COM组件，这样说不定可以解决ACE与MFC之间的配合问题！但是可惜，我们没有料到ACE与ATL之间的配合，居然也存在问题！当使用ACE_TP_Reactor或者ACE_Select_Reactor的时候，写出来的COM组件一定会报错，而且错误很难定位！讽刺的是，在采用MFC技术编写的COM组件，又不会有这个问题！也许我们可以忍受ACE与MFC之间的“小摩擦”带来的一点点内存泄漏，但是事实证明我们这个退而求其次的想法是多么的幼稚！在用MFC技术编写的COM组件中，在运用ACE_Task框架时，同样会遇到难以定位的错误！随后我们又尝试了采用标准C++ 编写的COM组件，同样遇到了各种各样的问题。至此，将我们采用ACE作为底层基础设施写成的网络层代码封装到COM组件中的尝试以失败告终。
其实在这期间出于对ACE底层机制的好奇，也看了一下POSAII，感觉ACE里面的很多组件确实设计精密，很多地方体现了高超的设计思想。但是从现实应用的角度来说，ACE太过于庞大，而没有明确细致的分类，相应的支持文档又过于单薄，在实际的工程应用中很可能会遇到很多难以解决的问题。也许，在下一个工程中，我应该抵制住ACE做出的种种承诺的诱惑，而选择不再采用ACE作为网络基础设施组件。
