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

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

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

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

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

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

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

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

全局變量仍然可能成為問題，因此您應(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è)計，甚至可能無法編譯。  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)的代碼全部使用在一個軟件包中，并在單獨(dú)的main軟件包中定義命令。這將允許您使用常見的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)用程序來支持兩個命令。

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

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

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

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

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

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

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

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

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