序文アップグレード前には徹底的な準備を行い、GoFrame V2の新機能を徹底的に調査した上で、アップグレードを決断しました。また、その調査結果を「開発者の視点からフレームワークの設計哲学を理解する」という記事にまとめました。 公式ドキュメントとは異なり、この記事は開発者の視点から、バージョンV1と比較したバージョンV2の利点をまとめ、共有するものです。また、130を超えるインターフェースを持つオープンソースのeコマースプロジェクトのアップグレードに携わった私自身の経験も盛り込み、遭遇した落とし穴についてもいくつか取り上げています。皆様のお役に立てれば幸いです。 オープンソースのEコマースシステムV2は現在開発中です。ぜひスターを付けてください: https://github.com/wangzhongyang007/goframe-shop-v2 Gin+Gorm+VUE をベースにした Five Blessings マーケティングおよびバイラル マーケティング プロジェクトも匿名化が進められており、後日オープンソース化されて、誰もが学習して使用できるようになります。 まず結論を述べる私はオープンソース プロジェクト「#オープンソース E コマース フロントエンドおよびバックエンド API システム: 実践的なアップグレードの旅」を使用することにしました。 これは初心者に適したモノリシックなプロジェクトです。130以上のインターフェースを開発しており、初心者から上級者まで幅広く対応しています。従来のeコマースに必要な基本機能に加え、高度な高並列処理ソリューションも備えています。 スターへようこそ: https://github.com/wangzhongyang007/goframe-shop 最終的に、私のプロジェクトの特定の状況に基づいて、私のエンジニアリング設計哲学は V2 で推奨されるエンジニアリング構造と大きく異なっていたため、V1 から V2 にアップグレードするのではなく、V2 を使用してオープンソース プロジェクトを書き直すことにしました。 慎重に検討した結果、V2のエンジニアリングアーキテクチャの方が優れていると考えています。ハードルは若干高いものの、プロジェクトの後期段階でのメンテナンスが容易になります。 練習すれば完璧になる私の研究と実践経験は今でも非常に貴重です。私のプロジェクトはV1からV2へのアップグレードに適していなかったため、V2を使って書き直しましたが、だからといってあなたのプロジェクトが適していないということではありません。この経験はまさに「川を渡る子馬」のようで、試行錯誤のプロセスなのです。 アップグレードの旅以下に、私のアップグレードの旅を紹介します。 1. まず、以前のバージョンを確認します。2. 依存ライブラリを置き換えるプロジェクト ファイルで、`github.com/gogf/gf/` のすべてのインスタンスを `github.com/gogf/gf/v2/` に置き換えます。 3. 指示に従ってエラーを解決します。コンポーネントを交換したら、実行してみてください。確かにエラーが発生しますが、問題ありません。表示されたエラーメッセージを修正してください。 プロンプトに従って関連する依存関係を取得するために `go get` を実行しようとしましたが、機能しませんでした。 4. フレームワークとCLIツールをアップグレードするプロジェクト内の依存パッケージを置き換えただけで、GoFrame フレームワークと GoFrame CLI ツールを更新していないことに突然気付きました。 さらに、公式ドキュメントによると、GoFrame は v1 と v2 の同時使用をサポートしていますが、同時使用には高いメンテナンス コストがかかるということが公式に推奨されています。 注: フレームワークはフレームワークであり、CLIはCLIです。これらを混同しないでください。公式ドキュメントには詳細な説明が記載されているため、ここでは繰り返しません。公式ドキュメント [1] CLIツールのアップグレード時に多くの問題が発生しました。公式ドキュメントを参考に、様々なアップグレード方法を見つけましたが、最初のいくつかは私の環境ではうまくいきませんでした。最終的に、以下の方法でアップグレードに成功しました。 wget - O gf https://github.com/gogf/gf/releases/latest/download/gf_$ ( go env GOOS ) _ $ ( go env GOARCH ) && chmod + x gf && ./gfインストール- y && rm ./gf 注: macOSでzshを使用している場合、エイリアスの競合が発生する可能性があります。「alias gf=gf」を実行することで解決できます。一度実行すると、gfツールがプロファイルのエイリアス設定を自動的に変更します。その後、再度ログイン（またはターミナルを再度開く）できます。 5. CLIのアップグレードが成功しましたCLI アップグレードのインストールが成功した場合のスクリーンショットの例: GF CLI バージョンが最新バージョンの v2.2.0 に更新されました。 6. データを定期的にバックアップするCLI のアップグレードには長い時間がかかり、さまざまな試行が必要だったため、良い習慣を身に付けるために、git にコミットして速やかにバックアップを取ることにしました。 CLIのアップグレード問題が解決し、ようやく一息つきました。さあ、新たな挑戦に向けて準備を整えましょう！ 7.gtokenのアップグレードgtokenの問題の解決は非常に簡単です。gtokenをアップグレードするだけです。公式ドキュメントに記載されているように、gtokenはGoFrame V2に完全に対応しています。 gtoken のインストールとアップグレードのチュートリアルは次のとおりです。
GOPATH モードを使用してインストールしたところ、スムーズに完了しました。次に、新しいエラーのトラブルシューティングに進みます。 8. GMVCの問題ドキュメントによると、GMVC は非推奨となり、今後サポートされなくなります。 9. gf CLI の最新バージョンは DAO を生成します。新たな挑戦に備えましょう。最新バージョンの gf CLI を使用して DAO を生成します。 嵐を歓迎する代わりに、それは立ち往生しました。 理由は冒頭で述べた通りです。
最新の CLI ツールでは、古いプロジェクト ディレクトリでのプロジェクト作成がサポートされなくなったことに注意してください。 10. プロジェクトのディレクトリ構造を調整するプロジェクトのディレクトリ構造を調整する必要があります。以下のリンクをご参照ください: https://GoFrame.org/pages/viewpage.action?pageId=30740166 プロジェクトのルート ディレクトリに内部ディレクトリを作成し、`gf gen dao` を実行したところ、依然として非常にスムーズでした。 11. V2 の gf gen dao を分析します。CLI の v2 バージョンでは、DAO レイヤーが生成されるだけでなく、モデル レイヤーが Do レイヤーと Entity レイヤーにさらに分割されることが分かりました。 この設計の理由については、時間があるときに公式ドキュメントで確認できます: https://GoFrame.org/pages/viewpage.action?pageId=30740166 ここでは結論のみを述べます。
`model` 内の `do` オブジェクトは、DAO データ操作中にビジネスモデルとインスタンスモデル間の変換に使用されるドメインオブジェクトです。これはツールによって管理されており、ユーザーが変更することはできません。 モデル内の実体はデータモデルです。データモデルは、モデルとデータセット間の1対1の関係です。これはツールによって管理され、ユーザーが変更することはできません。 12. 再度バックアップデータの取得を容易にするため、ディレクトリ構造を変更する前にローカルバックアップも作成しました。これにより、後でコードをコピー＆ペーストしやすくなり、参照も容易になります。 13. ディレクトリ構造を調整する公式推奨プロジェクトカタログ
以前のディレクトリ構造は、goFrame v1.xx の例に従って厳密に設計されたものではなく、プロジェクトのフロントエンドとバックエンドの要件に従ってカスタマイズされたためです。 したがって、スムーズなアップグレードには多大な作業が必要となり、多くのコードの変更が必要になる可能性が高いことがわかりました。 ドキュメントに基づいてプロジェクトのディレクトリ構造を変更しました。 13.1 APIレイヤーの移行先ほど書いた外部インターフェースに関連するコードを API レイヤーに移動しました。 13.2 DAOとモデルの参照パスを置き換える移行後に新たな問題が発生しました。 これを分析してみましょう。これまで実行してきた操作は単純に次のとおりです。
次に、インポート ディレクトリをグローバルに置き換えるだけです。 dao と model のディレクトリをグローバルに置き換えます。
上記の問題は無事解決されました。 14. 驚くべき問題を解決する新しい問題が発生しました。xxx が GOROOT に存在しないというメッセージが表示されます。 私は、shop プロジェクト ディレクトリを直接開くのではなく、goland を使用して go/src ディレクトリを開くことで問題を解決しようとしました。 この方法は非常にうまく機能し、プロジェクトの依存関係がすべて赤でフラグ付けされることはなくなり、GoLand も通知を提供します。 15. 構築制約問題の解決理由を分析してみましょう。新しいプロジェクトディレクトリは内部ディレクトリを使用しているため、制約が課せられます。つまり、外部インターフェースを公開するメソッドはapiディレクトリに配置し、公開する必要のないその他のロジックは内部ディレクトリに配置する必要があります。 さて、もう十分です。編集を続けましょう。 以前はビジネス ロジックを処理していた app ディレクトリ内のファイルを、internal ディレクトリに移動しました。 念のためお知らせ：プロジェクトのディレクトリは重要ではありません。GoFrame V2の原則に従い、外部ロジックを公開するにはapiディレクトリのみを使用します。外部に公開する必要のないロジックはすべて内部ディレクトリに配置してください。 16. プロジェクト ディレクトリと V2 推奨プロジェクト ディレクトリが一致しています。プロジェクトの特定のニーズに基づいて、ビジネス ロジック ファイルとディレクトリを移動して名前を変更したため、全体的なプロセスは非常にスムーズでした。 以前のプロジェクトでは共通パッケージとしてライブラリを使用していましたが、公式の推奨ではユーティリティディレクトリの使用が推奨されています。公式の推奨に従うことで、将来的にコミュニティ内でのコミュニケーションが容易になり、理解しやすくなります。 ディレクトリ構造を調整した後、改訂されたディレクトリ構造は基本的に公式に推奨されているディレクトリ構造と一致するようになりました。 その後、プログラムの実行を続け、エラーが発生しては解決しました。全体的に見て、問題は比較的簡単に解決できたので、詳細は省略します。 貴重な教訓は、多くの間違いを恐れないことです。リスト全体を見て共通点を見つけてください。これらの問題のほとんどは、指示に従うだけでスムーズに解決できます。 17. ビジネスロジックの移行ビジネス ロジックの移行中に新しい問題が発見されました。 公式の V2 の例を研究することで、サービス レイヤー内の各ファイルはインターフェイスとして定義され、サービス レイヤーはコードを通じて自動的に生成できることを知りました。 インターフェースが実装する必要があるメソッドを事前に定義するにはどうすればよいでしょうか? 答えは、ロジック層にコードを記述し、ツールを使用して対応するサービスファイルを生成し、ロジック層のinit()メソッド内でサービス層のRegisterXXX()メソッドを呼び出してサービスを登録することです。ご覧のとおり、複雑なロジックはロジック層で処理されます。 18. CLI経由でサービスを生成するCLI経由でサービスを生成することは、コードのこの部分をツールによって生成する必要があるため、非常に重要な操作です。そのため、まずこの概念を理解する必要があります。結論は以下のとおりです。
詳細については、公式ドキュメント「インターフェースメンテナンス - genサービス[3]」を参照してください。 19. 反省私が今学んだことは、バージョン 1 からバージョン 2 にアップグレードする前に、バージョン 2 の設計理念を理解しておく必要があるということです。そうしないと、アップグレード プロセスの途中で途方に暮れてしまいます。 これは、バージョン V2 の CLI ツールによって生成された dao とモデルが、バージョン V1 のものと一致していないためです。 一方、バージョン V2 では gf gen サービス アプローチもサポートされ、インターフェースのメンテナンス方法が統一されています。 この記事をもう一度読んでみることを強くお勧めします: # 開発者の視点からフレームワーク設計哲学を理解する フレームワーク開発者とユーザーの両方の観点から、V2 へのアップグレードに関する知識ポイントを学びます。 20. 「流域」問題これは重要な転換点です。アップグレードして移行するべきか、それともV2を使って直接書き直すべきか？ 決まった答えはありません。V2の新機能とエンジニアリング設計の原則を徹底的に理解し、既存プロジェクトの特性も考慮した上で決定する必要があります。 私のプロジェクトの特性に基づいて、GoFrame コミュニティのリーダーと慎重に分析およびコミュニケーションを行った結果、既存のプロジェクトに移行するのではなく、GoFrame V2 を使用して直接書き直すことにしました。 私のプロジェクト構造は v2 の設計理念とは大きく異なるため、アップグレードは書き直すことと同義になり、さらに多くの労力が必要になる可能性があります。 私のオープンソース プロジェクトのエンジニアリング設計は次のとおりです。
バックエンドは、電子商取引プラットフォームのバックエンド インターフェイスに対応します。 フロントエンドは、電子商取引プラットフォームのフロントエンド インターフェイスに対応します。
当然のことながら、私のアーキテクチャ設計とGoFrame V2のエンジニアリング設計は大きく異なります。慎重に検討した結果、最新バージョンのV2をベースにオープンソースプロジェクトを書き直すことにしました。皆様のご参加をお待ちしております。 要約「ウォーターシェッド」問題に遭遇する前は、GoFrame の v1 から v2 へのアップグレード プロセスは比較的スムーズでした。 また、コミュニティの全員とアップグレードの問題について話し合いました。ある専門家は、新しいプロジェクトを開始し、それを V2 を使用して書き直したと述べました。また、アップグレードは非常に簡単で、ディレクトリを変更するだけで、ビジネス ロジックは引き続き機能し、時間もかからないと述べた専門家もいました。 この問題は「川を渡る子馬」の物語のようで、誰もが自分のプロジェクトの具体的な状況を考慮する必要があります。
関連資料[1] 公式ドキュメント: https://GoFrame.org/pages/viewpage.action?pageId=1115790 [2] プロジェクトディレクトリの設計: https://GoFrame.org/pages/viewpage.action?pageId=30740166 [3] インターフェースメンテナンス - genサービス: https://GoFrame.org/pages/viewpage.action?pageId=49770772 [4] Goオープンソース電子商取引プロジェクトチュートリアル - チュートリアルの概要 + オープンソースアドレス: https://b23.tv/hdOpOTp この記事は、WeChat公式アカウント「プログラマーのレベルアップとモンスターとの闘いの旅」（著者：王中洋）からの転載です。以下のQRコードをスキャンしてアカウントをフォローできます。 この記事を転載する場合は、WeChat公式アカウント「プログラマーのレベルアップとモンスターとの戦いの旅」までご連絡ください。 |
