如果把各个模块比喻成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與方法的映射,權限驗證,分頁控制等等。 。
希望對你有幫助~~~