一般像JAVA伺服器開發已經是大家共同的約定，分成三層：ctroller、service、dao三層。

dao層主要資料庫操作；service層主要放邏輯程式碼，加上本地事務；ctroller這是一些對service層聚合呼叫和接收前端引數。

所以：最好是放置在服務層，同時可以提高程式碼的複用率。

前言

隨著網際網路的發展，大家熟知的專案也越來越多，也漸漸被人所熟悉，專案的生命週期也有長有短，除開一些市場，資金等問題，專案基礎工程的結構也是其中一個原因，一般專案從最開始三層結構，大家所熟悉的dao層，service層，controller層結構，在後續的最佳化迭代過程，可能也會衍生出其他層。其實在專案的開發過程當中，不分層做專案，當然也是可以做，那為什麼還是要做分層處理，邏輯計算到底放在哪裡以及各個層的職責又是什麼，接下來我分析一下。

在程式碼層面，類有幾個原則，其中單一職責原則也是其中一個，而工程結構也是一樣。基礎工程分層也意味這各層的職責不同，在專案開發過程中，DB操作，業務邏輯，API呼叫，分散式RPC呼叫，這些都是必不可少的，像最原始的開發，DB操作，業務邏輯，都在一個類方法裡面，每個不同的業務邏輯都會涉及到不同的資料表，每個方法裡面夾雜了各個資料庫操作，同一個DB操作，即使是同一條sql，都可能需要重新寫一遍，不利於擴充套件，更別說程式碼的複用了，所以，DAO只做資料庫層面的操作，增刪改查，並且儘量減少連表查詢，一方面比較清晰利於複用，另一方面，效能方面也比較好,後續的擴充套件最佳化都是有利的。而在service層一般用來做業務邏輯處理，一個功能模組可能會涉及到多張表，每個表都會有相應的業務邏輯。

Dao層只做資料庫操作，service層做業務邏輯處理，衍生出的元件層可以是基礎的業務組建，service可以對組建做組裝，四層結構更清晰一點。不要把複雜的邏輯計算放儲存過程，針對分散式資料庫或者分散式資料庫中介軟體，一般不支援儲存過程，儲存過程需要執行在底層資料節點，也意味著還是要在上層做合併處理，反而增大了複雜性，放棄擴充套件性，複用性，維護性，就為了解決減少資料庫互動次數，網路開銷等問題，得不償失。

畢竟網際網路公司的專案週期，質量，效能，快速迭代才是最重要，時間就是利潤。

看情況，資料關聯大，邏輯簡單，可以獨立完成的，複用率高的放在資料庫層，資料庫層負責把資料庫資料抽象成模型。有些類似sum avg 時間轉字元 某個差值，時間戳都可以在資料庫層完成。這些都是必要的，在模型初始化完畢就要完成的。不在之後進行單獨運算。

如果業務邏輯，是之後需要運算，或者和其他類進行互動的，放在業務層，資料庫層的資料儘可能保持乾淨，低耦合，不許其他類進行互動。業務層，可以用來銜接各個類(介面)的資料互動，主要是中介者和代理。

從csd結構來說。c要乾淨 d要乾淨 s負責銜接。