我們項目用的是傳統(tǒng)的mvc框架（CI框架），為了更好的復(fù)用業(yè)務(wù)邏輯，我們新增了services邏輯層，在開發(fā)過程中代碼復(fù)用性確實好了很多，但也遇到了問題：最明顯的就是service之間的互相調(diào)用，我感覺這增加了service之間的耦合性。本來最開始想按照業(yè)務(wù)邏輯分模塊劃分不同的service，每個service只提供自己業(yè)務(wù)相關(guān)的方法，由controller層分別去調(diào)用不同的service層方法得到數(shù)據(jù)，然后組裝成最終想要的數(shù)據(jù)輸送給view層。但是遇到個這個問題，我需要提供一個方法給同事調(diào)用，這個方法要求會做很多業(yè)務(wù)邏輯處理，這會涉及到多個service，這個方法如果寫在controller層，同事就無法在它的controller中使用，寫在controller的父類中感覺這個方法僅僅是他的控制器能用到，于是最終我寫在了一個service中，這個方法會分別去調(diào)用不同的service，然后組裝并輸出數(shù)據(jù)，這樣就產(chǎn)生了耦合。。不知道有沒有更好的解決方案，特別是在實際的開發(fā)過程中？然后就是model層的一些問題：我們原則上是一個數(shù)據(jù)表對應(yīng)一個model，每個model只負(fù)責(zé)對應(yīng)數(shù)據(jù)表的增刪改查，由service層按照業(yè)務(wù)邏輯去調(diào)用不同的model獲得數(shù)據(jù)，我們項目中很少有關(guān)聯(lián)查詢，這既有好處，也有壞處。有時關(guān)聯(lián)查詢更方便，但是這個查詢方法寫在哪個model里呢？放在哪個model的原則又是什么呢？最后，跨層調(diào)用不知道是否合理，有時controller層會直接調(diào)用model層。十分感謝。