使用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作爲網絡基礎設施組件。
我是在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作爲網絡基礎設施組件。