Q1：controller里面的Method如果參數(shù)比較多，會用一個類對象去接收，一般是放在dto包下，并且類名命名為FooDTO嗎？

A1：的確是放在dto包下面，但是我們這里的命名不會是FooDto，因為光看這個名字看不出這個類到底是干嘛的。我們針對查詢的：FooQueryParam，針對數(shù)據(jù)操作的：FooXXXCmd，XXX代表CRUD

Q2：返回給前端的對象，如果要求不高，并且單表直接Select出來，可以直接返回Entity或者List<Entity>。但是，如果是多張表join出來的結(jié)果，是不是需要定義一個類，比如命名為BarDTO，這個BarDTO通過MyBatis的ResultMap生成，并且經(jīng)過mapper -> service -> controller -> ajax？

A2：這個我們不會叫做BarDto，而是叫做BarVm，Vm代表ViewModel，意思是專供顯示用的Model，它可以根據(jù)具體情況將Entity的結(jié)果進(jìn)行轉(zhuǎn)換（比如身份證打碼），組合（多個Entity組合成一個Vm）等動作。

如果這個數(shù)據(jù)不是顯示的，就是一種數(shù)據(jù)，那么一般叫做BarData之類的，根據(jù)具體業(yè)務(wù)起不同的名字，總之不會叫Dto，就好像你不會給一個類取名為BarObject一樣。

Q3：第1點、第2點是不是在dto包下建立input、output包更好？input放controller參數(shù)的類，output用于存放service返回值的類

A3：不建議這么分，一個controller可能會有多種業(yè)務(wù)方法，傾向于根據(jù)業(yè)務(wù)方法分包，會更清晰一點。

Q4：controller和service之間傳遞的參數(shù)一般是不是直接傳DTO對象，然后在service中在構(gòu)造entity去調(diào)用mapper方法？

A4：service方法一般來說不應(yīng)該接收Dto參數(shù)，因為Dto是比較隨意的，而且會和Http請求聯(lián)系在一起，如果前端代碼變了，那么Service也很容易跟著變，這樣不好。

我建議是Controller將Dto轉(zhuǎn)換成service需要的參數(shù)類型，然后去調(diào)用service，這樣service代碼就會穩(wěn)定。

Q5：第4點，如果類對象成員比較多，勢必service方法充斥著很多set方法，如何解決呢？

A5：你可以使用Dozer，或者Orika Mapper之類的工具，將Dto的屬性copy到entity上，它們的原理是通過反射，將兩個類里的同名屬性做copy。

Q6：DTO的validation是在controller里面做，還是在service里面做呢？

A6：你可以借用Spring MVC提供的validation功能做一些簡單的校驗，比如@NotNull，@NotEmpty之類的。

但是如果你的這個FooSaveCmd有一些業(yè)務(wù)邏輯校驗，比如不允許注冊同名賬號，那么這個校驗得在service里做。

咋感覺是為了規(guī)范而規(guī)范，公司有公司的習(xí)慣，自己有自己的習(xí)慣，能解決問題，維護方便才是重點，一般都是實踐中找出最好的方式，或者看他人源碼。所以你這個不好回答，或者沒啥意義！
1.如果是維護他人的代碼，盡量按照之前 coder 編碼的風(fēng)格
2.如果沒有公司的約束，自己搭建的結(jié)構(gòu)，個人覺得其實都不重要，至少保證結(jié)構(gòu)清晰，至于以后會遇到什么問題，再具體分析，具體修改
樓下提到的阿里的Java規(guī)范，你可以看看

我的一些看法
1.controller里面的Method如果參數(shù)比較多，會用一個類對象去接收，一般是放在dto包下，并且類名命名為FooDTO嗎？
：數(shù)據(jù)傳輸對象:xxxDTO，xxx 為業(yè)務(wù)領(lǐng)域相關(guān)的名稱

2.返回給前端的對象，如果要求不高，并且單表直接Select出來，可以直接返回Entity或者2.List<Entity>。但是，如果是多張表join出來的結(jié)果，是不是需要定義一個類，比如命名為BarDTO，這個BarDTO通過MyBatis的ResultMap生成，并且經(jīng)過mapper -> service -> controller -> ajax？
：聯(lián)表查詢出來的數(shù)據(jù)，DO 設(shè)計的時候，我是會考慮的，當(dāng)然你也可以用 DTO，但是你要知道 DTO 如果設(shè)計的過多，分的太細(xì)，也是不好維護的

3.第1點、第2點是不是在dto包下建立input、output包更好？input放controller參數(shù)的類，output用于存放service返回值的類
4.controller和service之間傳遞的參數(shù)一般是不是直接傳DTO對象，然后在service中在構(gòu)造entity去調(diào)用mapper方法？
：還是那個問題，DTO 這個東西如果分的太多，太細(xì)，代碼維護和可讀性會有問題，關(guān)于頁面展示的可以用 VO；其實傳遞普通的基本的數(shù)據(jù)類型也是可以的呀，listUser(Interger groudId),getUser(String userid)，這個結(jié)構(gòu)不是也很清晰嗎，listUser(xxDTO xx),getUser(xxDTO xx)

5.第4點，如果類對象成員比較多，勢必service方法充斥著很多set方法，如何解決呢？
：充斥著很多set方法，我覺得ok呀，你可以封裝成一個方法，這本身就是屬于業(yè)務(wù)的一部分

6.DTO的validation是在controller里面做，還是在service里面做呢？
：具體還是看業(yè)務(wù)邏輯吧！

建議查看下阿里的JAVA開發(fā)規(guī)范，里面對dto、vo、po層的命名進(jìn)行了規(guī)范，可能每個公司的規(guī)范都不一樣，但至少養(yǎng)成自己的命名風(fēng)格。