Go扁平化項目結構是什么

這篇文章給大家分享的是有關Go扁平化項目結構是什么的內容。小編覺得挺實用的，因此分享給大家做個參考。一起跟隨小編過來看看吧。

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

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

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

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

有效使用平面結構

使用平面結構時，您仍應嘗試遵守編碼最佳實踐。您將需要使用不同的.go文件分隔應用程序的不同部分：

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

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

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()函數可能仍應在設置應用程序之外刪除大多數邏輯：

//警告：此示例非常人為設計，甚至可能無法編譯。

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)
}

實際上，您實際上可以將基本上是平面結構的代碼全部使用在一個軟件包中，并在單獨的main軟件包中定義命令。這將允許您使用常見的cmd子目錄模式：

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

在此示例中，您的應用程序基本上仍然是平坦的，但是您拔出了main軟件包是因為您有需要-例如可能需要使用同一核心應用程序來支持兩個命令。

為什么要使用扁平結構？

扁平結構的主要好處不是將所有代碼都保存在一個目錄中，也不是那樣愚蠢的東西。這種結構的核心好處是您可以不必擔心如何組織事物，而可以繼續解決您打算通過應用程序解決的問題。

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

這是正確的，因為我們可以不再擔心諸如“這種邏輯應該去哪里？”之類的問題。因為如果我們犯了一個錯誤，很容易解決。如果它是一個函數，我們可以將其移動到包中的任何新源文件中。如果它是錯誤類型的方法，我們可以創建兩個新類型并將邏輯與原始類型分開。有了這些，我們就不必擔心會遇到奇怪的周期性依賴問題，因為我們只有一個軟件包。

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

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

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

通過推遲創建新程序包的決定，直到我們的應用程序增長一點并更好地了解它，發芽的Gophers犯此錯誤的可能性就大大降低了。

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

平坦的結構并不全是陽光和彩虹

假裝使用扁平結構沒有任何不利之處，這對我來說是不誠實的，所以我們也應該討論這些。

對于初學者來說，扁平的結構只能使您受益匪淺。它會工作一段時間(可能比您想象的更長)，但是到某個時候，您的應用程序將變得足夠復雜，您需要開始分解它。使用平面結構的好處是您可以推遲使用它，并且在分解時可能會更好地理解您的代碼。缺點是，您將需要花一些時間進行重構，并且您可能(也許-但這很麻煩)發現自己已經重構為您想從任何地方開始的結構。

使用平面結構時，命名沖突有時也會很尷尬。例如，假設您想要在應用程序中使用Course類型，但是在數據庫中表示課程的方式與在JSON中呈現課程的方式不同。一個快速的解決方案是創建兩種類型，但是由于它們都在同一個包中，因此每種類型都需要使用不同的名稱，并且可能最終以類似以下內容的形式出現：SqlCourse和JsonCourse。這確實沒什么大不了的，但是有點令人遺憾的是我們最終得到了零類型，簡單地稱為Course。

將代碼重構為新程序包也不總是那么簡單。是的，這通常很容易，但是由于所有代碼都在一個包中，因此您有時可能會遇到天生具有周期性的代碼。例如，假設我們的課程是否具有在JSON響應中始終以crs_開頭的ID，并且我們想以各種貨幣返回價格。我們可以創建一個JsonCourse來處理：

輸入JsonCourse struct {
  ID字符串`json：“ id”`
  價格結構{
    USD字符串`json：“ usd”`
  }`json：“價格”`
}

同時，SqlCourse僅需要存儲一個整數ID和一個以美分為單位的單一價格，我們可以使用各種貨幣對其進行格式化。

type SqlCourse struct {
  ID    int
  Price int
}

現在我們需要一種將SqlCourse轉換為JsonCourse的方法，因此我們可以將其作為SqlCourse類型的方法：

func (sc SqlCourse) ToJson() (JsonCourse, error) {
  jsonCourse := JsonCourse{
    ID: fmt.Sprintf("crs_%v", sc.ID),
  }
  jsonCourse.Price.USD = Price: fmt.Sprintf("%d.%2d", sc.Price/100, sc.Price%100)
  return jsonCourse, nil
}

然后稍后我們可能需要一種方法來解析傳入的JSON并將其轉換為SQL等效項，因此我們將其添加到JsonCourse類型中作為另一種方法：

func (jc JsonCourse) ToSql() (SqlCourse, error) {
  var sqlCourse SqlCourse
  // JSON ID is "crs_123" and we convert to "123"
  // for SQL IDs
  id, err := strconv.Atoi(strings.TrimPrefix(jc.ID, "crs_"))
  if err != nil {
    // Note: %w is a Go 1.13 thing that I haven't really
    // tested out, so let me know if I'm using it wrong

感謝各位的閱讀！關于Go扁平化項目結構是什么就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！