就兩方的矛盾而言，其實也可以考慮這換個思路來利用三層架構。
首先，三層架構使界面層和業務層的編程人員不用考慮數據庫的設置問題，而按照相應的需求自行開發，提高了多方協同工作的效率，從整體上加快了編程速度。
但任何並行化帶來的實際是總體工作量的增加，而不是減少，包括接口設計、架構設計，代碼組織等，但爲什麼會提高進度呢，根本原因是更大限度的提高了每個人的開發效率。
三層開發的另一個問題是軟件的執行效率問題，直接寫sql語句、連表查詢、存儲過程等的執行效率肯定比ORM要強，但是編程時爲了可以實現調試往往顯示功能第一，其次是效率。
那麼我們就換個角度考慮問題。人們都看過冰雕，做冰雕的並不是一次將一個大方冰磚雕成美女，而是先做個輪廓，然後逐一去做細節，三層架構是一個很好的輪廓實現方法。在功能實現後，是可以在數據層增加特定接口或改寫接口的實現方式的，這樣我們就可以既保證了項目開發效率，又提高了軟件執行效率。
在後期系統優化過程中，即使是面向過程編程，也需要通過分析各模塊的執行速度來確定特定的優化方案，在此時引入特有的sql語句，並對數據層進行相應調整，也是非常合適的。從主要的優化工作看：
1. 運行速度優化： 提高系統運行的速度，一般運行速度慢的現象都是界面加載及更新慢，這裏面原因有佈局初始化、數據庫存取、無效阻塞、軟件BUG等很多因素。
2. 用戶支持能力優化： 使系統可以支持更大的併發用戶能力以及在更大規模的數據量情況保持系統速度， 此時我們往往採用異步處理、並行化、緩存系統等方式減少通信量、提高計算效率。
對於沒有使用了分層開發的系統，在此過程的優化時，我們往往會因爲在優化過程中擔心方法調用的耦合性而放棄很多可以大幅度提醒性能的方式，而如果使用了分層開發，由於各組件中的耦合度相對較低，只需要進行組件內調整，不會對其他組件產生影響。
而對於數據庫存取的優化，分層開發在此時的優化效率優勢就更加明顯， 因爲面向過程開發時，不可避免會產生大量的重複功能SQL語句， 很難一次理清，而對於分層開發，可以使用統一的經優化的接口，一次優化直接對多個模塊其作用。
在系統優化過程中，我們有時還會調整數據庫的表結構， 這對面向過程開發往往會是災難性的，因而會盡量避免，往往提高了優化難度，延長了時間，而分層開發可以以很小的代價就可以快速的實現相關優化。