ご支援ありがとうございます

CSDN で 100 以上のオリジナル記事を公開しています。私の記事を読んでいただけましたら、下のリンクをクリックして 5 つ星の評価をお願いします。

とても簡単です。下の画像をクリックして、スクリーンショットのように 5 つ星の評価を付けるだけです。

すべての質問に答えてください

最近、多くの読者から個人的にメッセージが届きました。なぜ e コマースプロジェクトの開発に GoFrame を選んだのですか?

理由は簡単です。

なぜなら、当社は e コマースビジネスの開発に GoFrame を使用しており、同僚は基本的に PHP を Go に変換しているからです。GoFrameはPHPerからGopherまで非常に適した開発フレームワークと言えます。

入社前はGinとgo-microフレームワークを使用していて、現在go-zeroを勉強中です。

開発言語も開発フレームワークも、私たちのビジネスに役立つものであり、ビジネスに関係なく言語やフレームワークについて語るのは意味がありません。

GoFrame をオープンソースプロジェクトとして使用するもう 1 つの理由は、V2 バージョンの新機能を体験したいためであり、歴史的な負担なく自分のプロジェクトを実行する方法について最終決定権を得ることができるからです。

序文

私の意見では、開発者が「モジュール内の高い凝集性、モジュール間の疎結合」をより良く達成できるようにすることが GoFrame V2 設計の本質です。

久しぶりに GoFrame で商用プロジェクトを開発してみましたが、GoFrame のバージョンアップは比較的早く、コミュニティも活発に行われていることがわかりました。

歴史的な理由により、私は商用プロジェクトの開発に V1.16 バージョンを使用してきましたが、個人的には V2 にアップグレードしたいという強い願望があります。

しかし、プロジェクトの安定性や開発コストなどの理由から、商用プロジェクトはアップグレードされていません。これは、多くの小規模パートナーが直面する問題でもあるかもしれません。

奨励されます

少し前に、私のオープンソースプロジェクト[Go WEB Advanced Practice] を共有しました。GoFrame に基づく電子商取引のフロントエンドおよびバックエンド API システムは、
みんなの注目とサポートを受けており、GoFrame の作者もそれを「いいね！」して転送しています。、さらに励まされます。

さらに重要なこと:コミュニティの多くの小規模パートナーから提案を受けていますが、最も多くの提案は、多くの新機能が提供され、ニーズをよりよく満たし、安定性と効率性を備えているため、V2 バージョンを使用することを提案することです。

アップグレードすることにしました

そこで、私はオープンソースプロジェクトをバージョン V1.16.x から最新バージョン V2.2.0 にアップグレードし、アップグレードの穴を踏み、アップグレード後の幸せを楽しむことにしました。

私のオープンソースプロジェクトに参加することを歓迎します。電子商取引のフロントエンドおよびバックエンドシステム API です。現在の V1 バージョンは、電子商取引プロジェクトの共通機能を含めて完成しており、120 を超えるインターフェイスが開発されています。

一緒に参加する

V2版の開発過程では、これまでに30以上のインターフェースが開発されており、今月中に開発を完了し、オープンソース化する予定だ。友人は共同構築に参加することを歓迎します。また、私のソースコードを読んで、より貴重な提案をすることも歓迎します。

V2 バージョンの GitHub アドレス

内容は比較的長く、核心的なものであるため、2 つの記事に分けて共有することにしました。

この記事の焦点: GoFrame V2 の新機能を紹介し、V1 と比較した利点は何ですか? 最大の変化は何ですか?
次の記事で共有します。V1から V2 までピットを踏んだ私の旅。多くの友人の役に立つと思います。

この経験は本当に簡単ではありません。友達がいいね、フォロー、ウェーブを転送してくれることを願っています。

群衆に適しています

Go の基本をマスターした後、成熟したフレームワークを使用してプロジェクトを開発したいパートナーは、私の記事を読んだ後、実際の開発には GoFrame の最新 V2 バージョンを使用することをお勧めします。
現在 V1 バージョンを使用している人、V2 の新機能を学ぶ意欲はあるがあまりエネルギーがない人、アップグレードの問題が心配で性急にアップグレードする勇気がない人。
新しい知識を学ぶ効率を高めたいと思っている友人は、私の実践を真似することを歓迎します。

開発者の観点から

どのような人であっても、公式ドキュメント、特にフレームワークの紹介をじっくり読むことをお勧めします。

公式ドキュメントとは異なり、この記事はフレームユーザーの観点から私自身の経験を組み合わせて、Goframe V2 バージョンの設計アイデアをより速くより良く理解するのに役立ち、V2 バージョンに基づいて商用プロジェクトをより適切に開発する方法を示します。

穴を踏んだ

バージョンをアップグレードする過程で、まず V2 の新機能を理解してから V1 から V2 にアップグレードする必要があることがわかりました。そうしないと、途中でアップグレードするときに問題が発生します。

CLI ツールの V2 バージョンによって生成された dao およびモデルは V1 バージョンと一貫性がないため、gmvc モジュールは破棄され、新しいモジュールも導入されます。
V2 バージョンでサポートされるメソッドgf gen serviceは、サービス層を生成し、インターフェースロジックの実装を統合し、ロジック層とサービス層の概念を導入します。

私自身のアップグレード経験と合わせて、GoFrame V2 を学習する際に知っておくべき知識ポイントを共有します。

知っている必要がある

プロジェクト構造が変更され、V2 標準に従う必要があります。これは、GF ツールによって生成されたコードのディレクトリ構造が変更されたためです。さらに重要なことに、V2 によって公式に推奨されているディレクトリ構造は、「高度な」作業を実践するのにも適しています。「凝集性と低結合」プロジェクトのディレクトリ構造。
gf gen daoV1と同様にdao層とモデル層が生成されるほか、do層とエンティティ層も生成されます
V2 バージョンのディレクトリ構造は、ビジネスモデルとデータモデルを分離するというアイデアを実践しました (これは非常に良いことだと思います)
V1 と比較すると、V2 では gmvc カップリングモジュールなどのメソッドまたはモジュールが破棄され、将来的にはサポートされなくなります。同時に、それを達成するためのより良い方法も提供します。
V2 は、サービスの登録が必要な「マイクロサービス」の作成に似ています。コントローラーは 1 つ以上のサービスを呼び出して特定のビジネスロジックを実装します。ただし、複雑なビジネスロジックはサービスに実装されません。分離するために、V2 バージョンは複雑なビジネスロジックを作成および再利用するためのロジックディレクトリを紹介します。サービスをロジックに登録し、サービス内のインターフェースを通じてロジック層に実装するメソッドを標準化します。

最優先

私が理解するのに時間がかかった知識ポイントを紹介します。

dao コード生成 (非常に重要)

GF ゲンダオ

ビジネスプロジェクトでは、dao/do/entityメソッドでデータベースを操作することが正式に推奨されており、これらのファイルは開発ツールによって自動生成され、開発ツールによって統一的に管理されます。

V1 バージョンと異なり、V2 バージョンでは do の概念が導入されていますが、なぜこのような設計になっているのでしょうか?

ここでは結論のみを述べますが、公式リンクは記事の最後に添付されます。

dao レイヤーはデータアクセスに使用されます。dao レイヤーは、基礎となるデータベースと対話するために使用される抽象オブジェクトのレイヤーであり、最も基本的な CURD メソッドのみが含まれます。
モデル層は構造モデル、つまりデータ構造管理モジュールであり、データエンティティオブジェクトを管理し、入出力データ構造を定義します。

2.1 モデル内の do は、dao データ操作におけるビジネスモデルとインスタンスモデル間の変換に使用されるドメインオブジェクトであり、ツールによって維持され、ユーザーが変更することはできません。

2.2 モデル内のエンティティはデータモデルであり、データモデルはモデルとデータコレクション間の 1 対 1 の関係であり、ツールによって維持され、ユーザーが変更することはできません。

後で例を挙げて説明します

サービスインターフェイスの生成 (より重要)

GFジェネサービス

サービスインターフェイスは非常に重要な知識ポイントであり、これが cli ツールのサポートと V1 バージョンの最大の違いであると思います。

ビジネスプロジェクト内のモジュール間の結合を減らすために、フレームワークはモジュール間の依存関係をインターフェイスに抽象化し、インターフェイスは内部/サービスパッケージによって維持されます。開発者が内部/サービスをカスタマイズしてインターフェースを維持することも、内部/ロジックビジネスによってカプセル化されたコードを通じて特定のルールに従ってインターフェースコードファイルを自動的に生成することもできます。

本当の知識は実践から得られる

文書を 10 回読んでも、1 回練習するほど効果はありません。皆さんも私と一緒に練習することをお勧めします。再現することは歓迎です:

私の思考回路は次のとおりです。

公式サンプルプロジェクトをダウンロードして、公式がどのように書かれているかを学びましょう。
自分で要件を提示し、公式の実装方法を参考にして、独自のビジネスシナリオを実現します。
製品情報の追加とクエリという、古典的な電子商取引のシナリオを理解してもらいます。

1. GitHub から公式サンプルをダウンロードして実行します

公式サンプル GitHub

1.1 プロジェクトをダウンロードしてデプロイした後、非常にスムーズに開始し、正常に開始します。

1.2 インターフェースを要求し、DB が正常に接続されていることを確認します。

1.3 データベースのクエリも重要です。

環境が正しいことを確認したら、V2 バージョンの新機能とエンジニアリング手法をよりよく理解するために、公式の例を参照して自分のニーズを実現してみましょう。

2. V2に基づいて商品管理を記述する

ピットに入るかどうかを確認するために、公式のエンジニアリング方法に従って練習してみましょう。

2.1 次のように商品テーブルを作成します。

2.2 gf gen dao による dao とモデルの生成

最初の試行は、ハックディレクトリ内の config.yaml 構成ファイルが変更されていなかったため、失敗しました。

注: V1 とは異なり、ハックディレクトリはプロジェクト開発ツール、スクリプト、その他のコンテンツを保存するツールスクリプトに使用されると公式は述べています。たとえば、CLI ツール、さまざまなシェル/バットスクリプト、その他のファイルの設定などです。そのため、V1 のように cli ツールの設定ファイルを manifest/config ディレクトリに書き込みません。

2.3 完了、正常に生成されました。

ヒント: テーブルを指定しない場合、すべてのテーブルに対応するデータが生成されます。私はこれを行うことを好みます。これにより、自分で複数のテーブルを変更することを回避できますが、構成ファイルに特定のテーブルがないと、予期しない問題が発生する可能性があります。

正式にコーディングを始めましょう:

最初は誰でも理解しやすいように書き、記事の最後に各モジュールのコードをどのような順番で書くのがより科学的であるかという私の実際の経験を共有します。

2.4 まず API 層を実装し、リクエストとレスポンスの構造を定義します。

2.5 cmdに商品関連のルートを登録します

2.6 ルートを登録するときに、このメソッドをまだ書いていないため、controller.Goods が赤色になっていることがわかりました。

サンプルコードを参照してコントローラー層を作成します。

右側のサンプルプロジェクトでは、メソッドがサービス内のメソッドを呼び出していることがわかりましたが、サービスをまだ定義していません。どうすればよいでしょうか?

まず、サンプルプロジェクトの user.go をクリックして、サービスに何が定義されているかを確認してみましょう。

ドキュメントを調べた結果、次のことがわかりました。

ロジック層を記述してビジネスロジックを実現し、golandプラグインを設定することでサービスコードを自動生成する必要があります。

これが公式が推奨するベストプラクティスである場合:

2.7 公式 XML ファイルをインポートします (構成は 1 回だけ必要です)

XMLファイルのアドレス

この構成を行った後、ロジック層のコードを記述すると、サービスはインターフェイス定義ファイルを自動的に生成できるようになります。

もちろん設定することもできませんが、ロジック業務モジュールの開発・更新後は毎回gf gen serviceコマンドを手動で実行する必要があります。面倒すぎる！！！

2.8 右の例を参考に、ビジネスロジックを処理する商品のロジックコードを記述します。

2.9 テストした結果、ロジックを記述すると、対応する商品ファイルとメソッドがサービス層で自動的に生成され、非常に便利であることがわかりました。

2.10 続けて商品の追加と商品の表示のロジックを書いてみましょう

ロジック層にプロダクトを追加するロジックを書くと、右側のサービス層にコードが自動生成されることがわかりました。

2.11 注意深い学生ならサービス層の RegisterGoods メソッドを発見したかもしれませんが、これはなぜ使用されるのでしょうか?

答えは、サービス層で RegisterXX() メソッドを生成した後、対応するビジネスモジュールにインターフェイスの実装インジェクションを追加する必要があるということです。

ヒント: このメソッドは、ビジネスモジュールごとに 1 回追加できます。

最初のロジックメソッドを作成した後 (またはサービス層が RegisterXX メソッドを生成した後)、次のことを行うことをお勧めします。

ロジック層の init 関数でサービスの登録を実現します。
次に、logic.go ファイルに関連する依存関係が追加されているかどうかを確認します。追加されていない場合は、手動で追加できます。

良いコーディング習慣を身につけ、バグを減らします。

2.12 ロジックディレクトリ内のlogic.goファイルを確認すると、今回書いた商品に関連するインポートが自動的に追加されていることが分かりました。

このファイルの機能は、プログラムの開始時にインターフェイスの特定の実装を登録することです。

さて、ロジックとサービスはこれで終わり、ビジネスロジックの記述が完了しました。

内容が豊富なので、上にスクロールしてこの部分をもう一度読み、消化して吸収することができます。

2.13 戻ってコントローラー層のコードを書き続けましょう。

公式のcontroller/user.goを参照して、商品を追加する独自のcontroller/goods.goメソッドを実装します。

2.14 この時点で、新しい要件の作成が完了しました。サービスを開始して効果を確認します。

わかりました。対応するインターフェイスを確認しました。

コーディングしたら、テストします。

インターフェースをリクエストして、表示するデータを追加してみましょう。

データはデータベースでも表示されます。挿入は成功し、プロセスは完了します。

振り返りレビュー

全体的には上記のプロセスに従ってください。個人的には、かなり混乱しているように感じます。

私自身の経験と合わせて、公式文書のエンジニアリング手法を消化して吸収するのに長い時間がかかりました。

V2 プロジェクトの作成プロセスをもう一度整理してみましょう。私の提案は次のとおりです。

仕上げ工程

デザインテーブルの構造
gf gen dao対応する dao/do/model ディレクトリコードを生成するために使用します。
API レイヤーを作成します。「ビジネスモジュール」のデータ構造を定義し、外部インターフェイスの入出力データ構造を提供します。
モデル層を作成します。「データモジュール」のデータ構造を定義し、内部データ処理のための入出力データ構造を提供します。
ロジック層を記述し、サービス層コードを自動生成します。( goland File Watcher の設定によって自動的に生成されるか、 gf gen サービスを通じて手動で実行されるスクリプト生成。前者を強く推奨します)
サービス層コードが RegisterXX() メソッドを生成した後、対応するロジックモジュールにサービスを登録します (各モジュールの書き込みは 1 回だけ必要です)。
コントローラー層を記述し、ユーザーが入力したパラメーターを受信/解析し、サービス層のサービスを呼び出します。
ルートを登録し、インターフェイスを外部に公開します。たとえば、このプロジェクトでは cmd.go ファイルを作成します。
main.go に line_ "project-name/internal/logic" を追加します (一度だけ書く必要があります)
main.go に _ "github.com/gogf/gf/contrib/drivers/mysql/v2" という行を追加します (mysql を使用している場合は、一度だけ記述してください)

主要なプロセス

新しい開発要件ごとに、上記のステップのうち 3 ～ 8 つだけが必要です
ステップ 1 と 2 は非常に簡単で、テーブル構造を設計し、コードを自動的に生成します。これはテーブルを追加または変更する場合にのみ必要です。
ステップ9と10はプロジェクト作成時に一度記述できます

もう一度練習してください

上記の手順に従ってクエリ製品ロジックを作成しましたが、全体的なプロセスは非常にスムーズです。

友達の皆さんも練習しましょう。私のオープンソースプロジェクト、スターフォークへようこそ: https://github.com/wangzhongyang007/goframe-shop-v2

質問しながら学ぶ

商品管理要件を書くときにいくつか疑問があります。

データ構造を 2 回定義する必要があるのはなぜですか? API 層で 1 回定義し、モデル層でもう一度定義しました。繰り返し構造を 2 回書きました。これはどういう意味ですか?

落ち着いて考えてみましたが、このデザインはまだ検討する価値があると思いますので、これまでのプロジェクト経験に基づいて理解を共有したいと思います。ご理解いただける場合は、コメント欄にメッセージを残してください。

以前の問題

以前、商品センターのユニファイドストレージを開発した際、ビジネスロジックとデータ処理ロジックが結合しているため、メンテナンスが難しいという問題に直面しました。

ビジネスの複雑化に伴い、プロジェクトのメンテナンスコストはますます高くなり、メンテナンスが困難なレベルに達しています。

どうやって解決したのでしょうか？

解決策は、GoFrame のデータモデルとビジネスモデルを分離することであり、基本的な考え方は同じです。

複雑なロジックを分割し、ビジネスモジュールとデータ処理モジュールを定義します。

「ビジネスモジュール」：受信したパラメータのみを処理し、値の格納および取得方法は考慮しません。「データモジュール」の要件に従って、フロントエンドから受信したデータを処理し、統一された構造をフロントエンドに渡します。「データモジュール」。

「データモジュール」：「ビジネスモジュール」の具体的な実装を気にする必要はありません。統一された入力標準が定義されており、ビジネスモジュールは独自の要件に従ってデータを均一にインポートする必要があります。データモジュールの検討の焦点オンデマンドで効率的に値を取得する方法は、ビジネス側の要件の変更を気にする必要はありません。

昇華する

冗長モジュールを解体し、「データモジュール」と「業務モジュール」の境界を整理することで、従来のプロジェクトのメンテナンスが困難であった問題を解決するとともに、お客様のニーズへの柔軟な対応力を向上させました。

私自身のプロジェクトの経験と、今回 V2 バージョンを実践した経験を組み合わせて、開発者が GoFrame V2 設計の本質である「モジュール内の高い凝集性とモジュール間の疎結合」をより良く実現できるようにする、ということから始めました。

さて、この記事はこれで終わりです。5,000 ワードの本格的な記事です。更新を主張するのは簡単ではありません。誰でも「いいね！」、コメント、転送を歓迎します。

やっと

この号の内容が良いと思われる場合は、3 回連続で支持してください。

以下に私の公式アカウントカードがあります。コードをスキャンしてフォローして、無料の本格的なプログラミング教材を受け取りましょう。

開発者の視点からフレームワークの設計思想を理解するにはどうすればよいでしょうか?