java開發運維程序員
前言
隨著互聯網的發展，大家熟知的項目也越來越多，也漸漸被人所熟悉，項目的生命週期也有長有短，除開一些市場，資金等問題，項目基礎工程的結構也是其中一個原因，一般項目從最開始三層結構，大家所熟悉的dao層，service層，controller層結構，在後續的優化迭代過程，可能也會衍生出其他層。其實在項目的開發過程當中，不分層做項目，當然也是可以做，那為什麼還是要做分層處理，邏輯計算到底放在哪裡以及各個層的職責又是什麼，接下來我分析一下。
基礎工程
在代碼層面，類有幾個原則，其中單一職責原則也是其中一個，而工程結構也是一樣。基礎工程分層也意味這各層的職責不同，在項目開發過程中，DB操作，業務邏輯，API調用，分佈式RPC調用，這些都是必不可少的，像最原始的開發，DB操作，業務邏輯，都在一個類方法裡面，每個不同的業務邏輯都會涉及到不同的數據表，每個方法裡面夾雜了各個數據庫操作，同一個DB操作，即使是同一條sql，都可能需要重新寫一遍，不利於擴展，更別說代碼的複用了，所以，DAO只做數據庫層面的操作，增刪改查，並且儘量減少連表查詢，一方面比較清晰利於複用，另一方面，性能方面也比較好,後續的擴展優化都是有利的。而在service層一般用來做業務邏輯處理，一個功能模塊可能會涉及到多張表，每個表都會有相應的業務邏輯。
網絡傳輸以及分佈式
Dao層只做數據庫操作，service層做業務邏輯處理，衍生出的組件層可以是基礎的業務組建，service可以對組建做組裝，四層結構更清晰一點。不要把複雜的邏輯計算放儲存過程，針對分佈式數據庫或者分佈式數據庫中間件，一般不支持存儲過程，存儲過程需要執行在底層數據節點，也意味著還是要在上層做合併處理，反而增大了複雜性，放棄擴展性，複用性，維護性，就為了解決減少數據庫交互次數，網絡開銷等問題，得不償失。
結語
畢竟互聯網公司的項目週期，質量，性能，快速迭代才是最重要，時間就是利潤。
億月
看情況，數據關聯大，邏輯簡單，可以獨立完成的，複用率高的放在數據庫層，數據庫層負責把數據庫數據抽象成模型。有些類似sum avg 時間轉字符 某個差值，時間戳都可以在數據庫層完成。這些都是必要的，在模型初始化完畢就要完成的。不在之後進行單獨運算。
如果業務邏輯，是之後需要運算，或者和其他類進行交互的，放在業務層，數據庫層的數據儘可能保持乾淨，低耦合，不許其他類進行交互。業務層，可以用來銜接各個類(接口)的數據交互，主要是中介者和代理。
從csd結構來說。c要乾淨 d要乾淨 s負責銜接。
小汐vivi
一般像JAVA服務器開發已經是大家共同的約定，分成三層：ctroller、service、dao三層。
dao層主要數據庫操作；service層主要放邏輯代碼，加上本地事務；ctroller這是一些對service層聚合調用和接收前端參數。
所以：最好是放置在服務層，同時可以提高代碼的複用率。
閉著眼睛切土豆
其實看你的數據量和查詢所佔用的時間，如果邏輯放在應用端來進行處理的話，查詢不是很慢，還過得去的話，那就放在sql端，畢竟你的代碼可能會進行升級或者是二次開發的，所以可維護性是要考慮的。
如果實在比較慢，或者是數據量比較大的話，那就考慮sql優化，或者是寫存儲過程吧。那樣會好一點。
因為你已經是老系統，且已經有大量的業務數據！！！
對於業務邏輯到底該放到數據庫層、中間件層哪個裡面才比較好，早期做開發的放到數據庫層面，用存儲過程編寫，減小協議傳輸的大小，同時SQL也不需要再進行編譯，不存在大量的硬解析，效率要高。
現在的新的開發架構，考慮未來的發展與應用，都是放到中間件， 就一句話，大型系統 用存儲過程效率低，拋棄了存儲過程，業務處理當然是放在中間層， 只有涉及到需要對錶進行處理訪問才會訪問數據庫
