無(wú)需花時(shí)間試圖弄清楚如何將代碼分解為軟件包，而是采用扁平結(jié)構(gòu)的應(yīng)用程序會(huì)將所有.go文件放置在一個(gè)軟件包中。

myapp/   main.go   server.go   user.go   lesson.go   course.go

進(jìn)入Go時(shí)，幾乎每個(gè)人都從一個(gè)平面應(yīng)用程序結(jié)構(gòu)開(kāi)始。 Go tour中的每個(gè)程序，Gophercises中的大多數(shù)練習(xí)以及許多其他早期的Go程序都沒(méi)有被分解成任何包裝。取而代之的是，我們只創(chuàng)建幾個(gè).go文件，然后將所有代碼放入相同的(通常是main)包中。

起初，這聽(tīng)起來(lái)很糟糕。代碼會(huì)很快變得笨拙嗎？如何將業(yè)務(wù)邏輯與UI渲染代碼分開(kāi)？我如何找到正確的源文件？畢竟，我們使用軟件包的很大一部分原因是要分離關(guān)注點(diǎn)，同時(shí)使更容易快速地導(dǎo)航到正確的源文件。

相關(guān)學(xué)習(xí)推薦：Go語(yǔ)言教程

有效使用平面結(jié)構(gòu)

使用平面結(jié)構(gòu)時(shí)，您仍應(yīng)嘗試遵守編碼最佳實(shí)踐。您將需要使用不同的.go文件分隔應(yīng)用程序的不同部分：

myapp /   main.go#閱讀配置并在此處啟動(dòng)您的應(yīng)用   server.go#總體HTTP處理邏輯在這里   user_handler.go#用戶http處理程序邏輯在這里   user_store.go#用戶數(shù)據(jù)庫(kù)邏輯在這里   # 等等...

全局變量仍然可能成為問(wèn)題，因此您應(yīng)考慮將類型與方法配合使用，以使它們脫離代碼：

type Server struct {   apiClient *someapi.Client   router *some.Router }  func (s *Server) ServeHTTP(w http.ResponseWriter, r *http.Request) {   s.router.ServeHTTP(w, r) }

而且您的main()函數(shù)可能仍應(yīng)在設(shè)置應(yīng)用程序之外刪除大多數(shù)邏輯：

//警告：此示例非常人為設(shè)計(jì)，甚至可能無(wú)法編譯。  type Config struct {   SomeAPIKey     string   Port           string   EnableTheThing bool }  func main() {   var config Config   config.SomeAPIKey = os.Getenv("SOMEAPI_KEY")   config.Port = os.Getenv("MYAPP_PORT")   if config.Port == "" {     config.Port = "3000"   }   config.EnableTheThing = true    if err := run(config); err != nil {     log.Fatal(err)   } }  func run(config Config) error {   server := myapp.Server{     APIClient: someapi.NewClient(config.SomeAPIKey),   }   return http.ListenAndServe(":" + config.Port, server) }

實(shí)際上，您實(shí)際上可以將基本上是平面結(jié)構(gòu)的代碼全部使用在一個(gè)軟件包中，并在單獨(dú)的main軟件包中定義命令。這將允許您使用常見(jiàn)的cmd子目錄模式：

myapp/   cmd/     web/       # package main       main.go     cli/       # package main       main.go   # package myapp   server.go   user_handler.go   user_store.go   ...

在此示例中，您的應(yīng)用程序基本上仍然是平坦的，但是您拔出了main軟件包是因?yàn)槟行枰?例如可能需要使用同一核心應(yīng)用程序來(lái)支持兩個(gè)命令。

為什么要使用扁平結(jié)構(gòu)？

扁平結(jié)構(gòu)的主要好處不是將所有代碼都保存在一個(gè)目錄中，也不是那樣愚蠢的東西。這種結(jié)構(gòu)的核心好處是您可以不必?fù)?dān)心如何組織事物，而可以繼續(xù)解決您打算通過(guò)應(yīng)用程序解決的問(wèn)題。

我絕對(duì)喜歡這個(gè)應(yīng)用程序結(jié)構(gòu)讓我回想起PHP的日子。當(dāng)我第一次學(xué)習(xí)編碼時(shí)，我開(kāi)始使用隨機(jī)PHP文件，其邏輯與各種HTML混合在一起，這真是一團(tuán)糟。我并不是在建議我們以大型應(yīng)用程序的方式構(gòu)建-那樣會(huì)很糟糕-但是我并不擔(dān)心一切都應(yīng)該放在哪里，而是更加關(guān)注學(xué)習(xí)如何編寫(xiě)代碼和解決我的特定問(wèn)題。無(wú)論您是要了解應(yīng)用程序的需求，您的域還是一般的編碼方式，使用扁平結(jié)構(gòu)都可以使您更輕松地專注于學(xué)習(xí)和構(gòu)建。

這是正確的，因?yàn)槲覀兛梢圆辉贀?dān)心諸如“這種邏輯應(yīng)該去哪里？”之類的問(wèn)題。因?yàn)槿绻覀兎噶艘粋€(gè)錯(cuò)誤，很容易解決。如果它是一個(gè)函數(shù)，我們可以將其移動(dòng)到包中的任何新源文件中。如果它是錯(cuò)誤類型的方法，我們可以創(chuàng)建兩個(gè)新類型并將邏輯與原始類型分開(kāi)。有了這些，我們就不必?fù)?dān)心會(huì)遇到奇怪的周期性依賴問(wèn)題，因?yàn)槲覀冎挥幸粋€(gè)軟件包。

考慮平面結(jié)構(gòu)的另一個(gè)重要原因是，隨著應(yīng)用程序復(fù)雜性的提高，結(jié)構(gòu)的發(fā)展變得容易得多。當(dāng)您明顯可以從將代碼拆分到一個(gè)單獨(dú)的程序包中受益時(shí)，您通常需要做的就是將一些源文件移到一個(gè)子目錄中，更改其程序包，并更新任何引用以使用新的程序包前綴。例如，如果我們有SqlUser并決定從一個(gè)單獨(dú)的sql包中處理所有與數(shù)據(jù)庫(kù)相關(guān)的邏輯中受益，我們將更新所有引用以現(xiàn)在使用sql.User將類型移動(dòng)到新軟件包后。我發(fā)現(xiàn)，像MVC這樣的結(jié)構(gòu)在重構(gòu)方面更具挑戰(zhàn)性，盡管并非沒(méi)有其他編程語(yǔ)言那樣困難或困難。

扁平結(jié)構(gòu)對(duì)于通常太快無(wú)法創(chuàng)建包的初學(xué)者特別有用。我真的不能說(shuō)為什么會(huì)發(fā)生這種現(xiàn)象，但是Go的新手喜歡創(chuàng)建大量的軟件包，這幾乎總是導(dǎo)致口吃(user.User)，周期性依賴關(guān)系或其他一些問(wèn)題。

在下一篇有關(guān)MVC的文章中，我們將探討這種創(chuàng)建過(guò)多包的現(xiàn)象如何使MVC在Go中顯得不可能的方法，盡管事實(shí)并非如此。

通過(guò)推遲創(chuàng)建新程序包的決定，直到我們的應(yīng)用程序增長(zhǎng)一點(diǎn)并更好地了解它，發(fā)芽的Gophers犯此錯(cuò)誤的可能性就大大降低了。

這也是為什么很多人會(huì)鼓勵(lì)開(kāi)發(fā)人員避免過(guò)早將其代碼分解到微服務(wù)中的原因-您通常沒(méi)有足夠的知識(shí)來(lái)真正知道應(yīng)該和不應(yīng)該將哪些內(nèi)容分解為微服務(wù)以及搶先式微服務(wù)( I kinda希望能成為一句俗語(yǔ))只會(huì)在將來(lái)帶來(lái)