[CSスタック]サーバフレームワーク(MVC構造)
一人でプロジェクトをするとき、このプロジェクトを通じて最も関心のないサーバ構造をたくさん知りました.多くの協力者とルールを作って、ルールに従って開発して、設計を助けて、私は多くのことを学んだので、私の知っている範囲内でできるだけ残したいと思っています.
📕 フレームワークの概念
フレームワークは、ある目的を達成するために複雑な問題を解決するための構造であり、ソフトウェア開発のスケルトンである.通常、フレーム=クラス+ライブラリをフレームと見なすだけでライブラリが混同されます.フレームワークはより高度な概念です.フレームワークは,特定のプログラムを開発するために複数の要素とメニューバインド規則を提供するプログラムとして,ユーザにとって高可用性のツールであるといえる.
📒 MVC構造
今回議論する内容は,Web APIサーバMVC構造である.
MVC構造は、ドメインレポートサービスコントローラからなる.
△まだいくつかの異なる構造があるようですが、大きなフレームワークは似ているように見えます.
このように分ける理由は抽象化のためであるべきだ.各層が異なり,各層間の抽象性が良ければ依存性が低く,交換も容易である.
1. Domain
ドメインは、ビジネスドメインオブジェクトを含む場所です.開発当時はdbテーブルに入れやすい場所だと思っていました.(domainのオブジェクトを使用してdbが自動的に移行したためです.)
次の構造を作成して使用します.dbテーブルの内容と脈絡があるのでprimaryKeyを指定するかdefault値を宣言します.
DBに直結しているところ.ここでクエリー文を作成し、データの処理方法をメソッドに設定すればいいです.単純DBと関係のある部分だけが可能です.
ビジネスロジックを含むメソッドとメソッド名を選択する必要があります.主に1つのロールとして開発され、複数のロールを実行する場合は、1つのプロセスで実行するためにトレーストランザクションチェックなどを作成する必要があります.(rollbackなどを使用)
いろいろな役割を果たすという意味で、いろいろなrepoを歌います.repoは簡単なdb操作のための方法であるため,1つの作業のみを実行する.
(ここでは、1つのロールと1つのロールの違いが混同される可能性があります.1つのロールが重複チェックである場合、1つのロールがidを所有し、このメールをインポートし、電子メールで重複チェックを実行する可能性があります.)
クライアントに最も近い場所として、サービスを使用してビジネスロジックを処理します.直接論理を含まないで、サービスを呼び出す形式で使用します.
一番外側からController->Services->Repositoryに入り、互いの心を知らない.つまり、コントローラはレポートを直接呼び出すことはできません.必ずサービスで歌います.したがって、コントローラは複数のサービスを呼び出すことができるので、それらが最大であると考えられる.
1. package
パッケージは、関連ライブラリを使用して作成されたメソッドを収集する場所です.どこにでも貼り付けることができる必要があるため、プロジェクト内でのみ使用されるフォーム、ドメインは使用できません.
たとえばawss 3関連メソッド、iot関連メソッドを作成する場所.
2. form
上記では書かれていませんが、これらのメソッドのinput、outputのformを作成し、これらのメソッドのフォームを同時に管理する場所です.開発後期には,設計ドキュメントと比較する際にパラメータと応答値を一度にチェックすることができ,非常に有用である.
3. config
環境変数を収集するときに使用する場所です.ライブラリまたは外部apiを使用する場合、定数として保存するのではなく、環境変数を変更し、単独で変数化して整理する必要がある場合は、他の協力者が使用できます.
🐾 成長日記
一つの構造を把握しているので、異なる構造と違いを区別しやすい.また,衆口難調開発に比べて,ある枠組みがあり,方法間の役割が区別されやすく,互いに抽象的で,安全性がより良く,依存性が減少し,非常に便利である.
📕 フレームワークの概念
フレームワークは、ある目的を達成するために複雑な問題を解決するための構造であり、ソフトウェア開発のスケルトンである.通常、フレーム=クラス+ライブラリをフレームと見なすだけでライブラリが混同されます.フレームワークはより高度な概念です.フレームワークは,特定のプログラムを開発するために複数の要素とメニューバインド規則を提供するプログラムとして,ユーザにとって高可用性のツールであるといえる.
📒 MVC構造
今回議論する内容は,Web APIサーバMVC構造である.
MVC構造は、ドメインレポートサービスコントローラからなる.
△まだいくつかの異なる構造があるようですが、大きなフレームワークは似ているように見えます.
このように分ける理由は抽象化のためであるべきだ.各層が異なり,各層間の抽象性が良ければ依存性が低く,交換も容易である.
1. Domain
ドメインは、ビジネスドメインオブジェクトを含む場所です.開発当時はdbテーブルに入れやすい場所だと思っていました.(domainのオブジェクトを使用してdbが自動的に移行したためです.)
次の構造を作成して使用します.dbテーブルの内容と脈絡があるのでprimaryKeyを指定するかdefault値を宣言します.
type Customer struct {
Id uint `gorm:"primaryKey"`
Email string
Password string
PhoneNumber string
LoginType uint
CreatedAt time.Time `gorm:"autoCreateTime"`
UpdatedAt time.Time `gorm:"autoUpdateTime"`
DeletedAt gorm.DeletedAt
}
2. RepositoryDBに直結しているところ.ここでクエリー文を作成し、データの処理方法をメソッドに設定すればいいです.単純DBと関係のある部分だけが可能です.
func (repo *Repository) CreateCustomer(cu c.Customer) (c.Customer, error) {
err := repo.db.Create(&cu).Error
if err != nil {
return c.Customer{}, err)
}
return cu, nil
}
3. Serviceビジネスロジックを含むメソッドとメソッド名を選択する必要があります.主に1つのロールとして開発され、複数のロールを実行する場合は、1つのプロセスで実行するためにトレーストランザクションチェックなどを作成する必要があります.(rollbackなどを使用)
いろいろな役割を果たすという意味で、いろいろなrepoを歌います.repoは簡単なdb操作のための方法であるため,1つの作業のみを実行する.
(ここでは、1つのロールと1つのロールの違いが混同される可能性があります.1つのロールが重複チェックである場合、1つのロールがidを所有し、このメールをインポートし、電子メールで重複チェックを実行する可能性があります.)
func (ser *Service) CheckDuplicate(id) (bool, error) {
u, err := ser.GetEmail(id)
if err != nil {
return false, err
}
isDuplicated := func(Email string) bool {
return len(Email) != 0
}
return isDuplicated(u.Email), nil
}
4. Controllerクライアントに最も近い場所として、サービスを使用してビジネスロジックを処理します.直接論理を含まないで、サービスを呼び出す形式で使用します.
一番外側からController->Services->Repositoryに入り、互いの心を知らない.つまり、コントローラはレポートを直接呼び出すことはできません.必ずサービスで歌います.したがって、コントローラは複数のサービスを呼び出すことができるので、それらが最大であると考えられる.
func (co *Controller) Login(c echo.Context) error {
params := make(map[string]string)
if err := c.Bind(¶ms); err != nil {
return err
}
id := c.QueryParam("id")
pwd := c.QueryParam("password")
nu, err := co.Service.GetUser(id,pwd)
if err != nil {
return err
}
res := nu.user
return c.JSON(http.StatusOK, res)
}
📗 サーバ構造の向上1. package
パッケージは、関連ライブラリを使用して作成されたメソッドを収集する場所です.どこにでも貼り付けることができる必要があるため、プロジェクト内でのみ使用されるフォーム、ドメインは使用できません.
たとえばawss 3関連メソッド、iot関連メソッドを作成する場所.
2. form
上記では書かれていませんが、これらのメソッドのinput、outputのformを作成し、これらのメソッドのフォームを同時に管理する場所です.開発後期には,設計ドキュメントと比較する際にパラメータと応答値を一度にチェックすることができ,非常に有用である.
3. config
環境変数を収集するときに使用する場所です.ライブラリまたは外部apiを使用する場合、定数として保存するのではなく、環境変数を変更し、単独で変数化して整理する必要がある場合は、他の協力者が使用できます.
🐾 成長日記
一つの構造を把握しているので、異なる構造と違いを区別しやすい.また,衆口難調開発に比べて,ある枠組みがあり,方法間の役割が区別されやすく,互いに抽象的で,安全性がより良く,依存性が減少し,非常に便利である.
Reference
この問題について([CSスタック]サーバフレームワーク(MVC構造)), 我々は、より多くの情報をここで見つけました https://velog.io/@ssuh0o0/CS-스택쌓기-서버-프레임워크-구조-MVC구조テキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol