如果把各个模块比喻成U盘,下图是我认为的架构模式
如图,个人感觉业务的接口应该要Web端来定义,而具体的业务实现放在业务模块,
认证0级讲师
我有點孤弱寡聞，只聽過mvcmodel view controller你的理解方式不太對業務接口是在你所說的web裡面調用，但不能把接口就說放在web裡面，業務介面是公用的東西，它可能還被其他web調用，它是抽象的，方便解耦，但它還是業務，不能歸到web裡面，dao也是一樣的
感覺你對介面不是很理解，它主要是解耦和反射，並不是直接歸類到web
可能你想的是介面提供規範，業務需求改變不影響web程式碼－這是對的，但這是介面的功用，不是架構，感覺你搞得很混淆
大部分都是這麼寫的。 不過Web是接受使用者輸入的，service的才是業務的介面。 出了這種還有DDD，可以看一下
1、service層是業務的接口，web層是來接受用戶請求的。 2、service層的方法，不只起到解耦的作用，而且可以被web層重複使用。 3.controller層，或是RPC層負責接受web請求，進行url與方法的映射，權限驗證，分頁控制等等。 。
希望對你有幫助~~~
我有點孤弱寡聞，只聽過mvc
model
view
controller
你的理解方式不太對
業務接口是在你所說的web裡面調用，但不能把接口就說放在web裡面，業務介面是公用的東西，它可能還被其他web調用，它是抽象的，方便解耦，但它還是業務，不能歸到web裡面，dao也是一樣的
感覺你對介面不是很理解，它主要是解耦和反射，並不是直接歸類到web
可能你想的是介面提供規範，業務需求改變不影響web程式碼－這是對的，但這是介面的功用，不是架構，感覺你搞得很混淆
大部分都是這麼寫的。
不過Web是接受使用者輸入的，service的才是業務的介面。
出了這種
還有DDD，可以看一下
1、service層是業務的接口，web層是來接受用戶請求的。
2、service層的方法，不只起到解耦的作用，而且可以被web層重複使用。
3.controller層，或是RPC層負責接受web請求，進行url與方法的映射，權限驗證，分頁控制等等。 。
希望對你有幫助~~~