CRUDジェネレーターDBuilder、crudジェネレーターdbuilderの設計と実装

CRUD ジェネレーター DBuilder の設計と実装、CRUD ジェネレーター DBuilder

第 1 章 概要

1.1 研究の背景と意義

コンピュータソフトウェア技術の発展により、データベースはフォーマットされたデータを保存するために最も広く使用される媒体となり、データベースプログラム開発技術もますます完成し、データベースプログラム開発を簡素化し、運用の主流になりました。リレーショナルデータベース。データベース プログラムの主要なコードは CRUD (作成、取得、更新、削除) コードです。ORM フレームワーク機能の改良により、CRUD コードを作成することにより、別のデータベース テーブル上で動作する CRUD コードも高度に再利用できます。 。現在、開発者は繰り返し CRUD コードを記述することが常態となっており、開発者の熱意が著しく低下するだけでなく、開発効率も低下します。そのため、この作業を軽減するために、CRUD コードを迅速に生成できる製品が急務となっています。開発効率を向上させます。

1.2 研究状況

現在、海外ではCrudKit、CRUD-Admin-Generator、Dadabik、GroceryCrud、SximoBuilderといった、上記のニーズを解決するユーザビリティの高いCRUDジェネレーター製品が生まれています。これらの製品にはそれぞれ独自の特徴がありますが、共通点もあります。それは、すべて PHP に基づいて開発されているということです (これは、PHP 構文の柔軟性と解析によってある程度決まります)。代表的なものとしては SximoBuilder が挙げられます。 SximoBuilder は、デザインが独特で使いやすさが高く、人気も高いのですが、次のような欠点もあります。

カスタム フォーム コントロールはサポートされていません;

• 複数のデータベースはサポートしません;
• 検証ルールが不完全で、非同期検証はサポートされていません。
• コードは非常に冗長です。
• しかし、今日のますます複雑化する Web プログラムでは、上記の点は開発プロセス中に考慮する必要がある問題であるため、SximoBuilder の既存の機能を備えているだけでなく、その欠点を改善した CRUD ジェネレーター製品の開発が不可欠です。

1.3 研究内容

国内外の CRUD ジェネレーターの研究状況を踏まえ、著者は DBuilder (D は DataAdministrator の略) と呼ばれる CRUD ジェネレーターを開発しました。

DBuilder は、モジュールがコード単位であり、コードがテンプレートから生成されるという SximoBuilder の考え方を利用していますが、コード生成ロジックは SximoBuilder とは完全に異なります。 SximoBuilder のコア コード生成と一般的な CRUD 機能の実現に基づいて、コード ロジックを書き換えることでその欠点 (大規模なコードの冗長性とフロントエンド検証の欠如) を改善します。

第 2 章 DBuilder システム分析

DBuilder の主なユーザー グループは Web バックエンド管理者と開発者であるため、そのシステム分析プロセスでは、より Web バックエンド管理者と開発者の観点から問題が考慮されます。

2.1 要件分析

プロジェクトは次のコア機能を実装する必要があります。

1)

データソース管理 ユーザーはインターフェースでプロジェクトの複数のデータソースを設定できます。設定されたデータ ソース情報には、データベースの種類、アドレス、データベース名、ポート、ユーザー名、パスワード、その他の情報が含まれます。データ ソースの追加、削除、変更、クエリをサポートし、データ ソースの追加、削除、変更、クエリによってシステムの問題が発生しにくくなります。

2)

コード生成

この機能は、データ ソースとデータ テーブルを選択した後、フォーム構成、リスト (テーブル) リスト構成、リレーションシップ構成、およびグローバル属性を含むデータベース テーブルのフィールドを簡単に構成できます。 。 構成。構成が完了したら、DBuilder はデータベース テーブルの CRUD MVC コードを生成できる必要があります。つまり、コードを記述せずに CRUD 利用可能な関数を実装する必要があります。

3)

データベース

テーブルCRUD

生成されたコードは、データ テーブル レコードの作成、削除、更新、およびクエリ操作をサポートする必要があります。

4)

メニュー管理

DBuilder は、ユーザーがメニュー項目をクリックした後に DBuilder によって生成された CRUD 関数を使用できるように、生成されたコードをメニュー項目にバインドできる必要があります。このメニューにはバックグラウンド メニューが含まれている必要があります。フロント メニューは必要ありません。

5)

ユーザー管理

ユーザーは複数の役割を実現する必要があります。電子メール アドレスは、ユーザーの一意の識別子として、またログイン パラメーターとして使用できなければなりません。将来的には、OAuth2.0 に基づく QQ、WeChat、Sina Weibo の相互接続ログインのサポートも実装する予定です。

6)

権限管理

DBuilder は、さまざまなユーザー ロールに対するさまざまな CRUD コードの実行およびアクセス権の 3 次元構成機能を実装できなければなりません。たとえば、記事管理用の CRUD 機能モジュールがあり、ユーザーの役割がシステム管理者 (SuperAdmin)、管理者 (Admin)、ゲスト (Guest) に分かれており、DBuilder は次のような 3 次元の権限設定を実装できる必要があります。そしてそれをすべてのモジュールのデフォルトの権限として使用します。

表 2-1 モジュール権限設定表

ユーザーグループと権限	見る	編集	削除	エクスポート
スーパー管理者	√	√	√	√
管理者	√	√	√
ゲスト	√

7) サイトパラメータ設定

DBuilder は、Web サイトの Web バックグラウンド プログラムとして、サイトのグローバル パラメーターを構成するためにも必要です。これらのパラメーターには、Web サイト名、キーワード、連絡先アドレス、フレンドリー リンクなどが含まれます。

8) 操作ログ

DBuilder は、訪問したページ、実行された CRUD の種類、時間、その他の情報を含むユーザーの操作情報を記録する必要があります。ログ記録形式は、データベースとファイルの 2 つの方法をサポートしています。

9) 複数の言語サポート

DBuilder は複数の言語間の切り替えをサポートする必要があります。中国語と英語の少なくとも 2 つの言語がサポートされる必要があり、中国語がデフォルトになります。

10) 複数のデータベースタイプをサポート

DBuilder は複数の種類のデータベースをサポートする必要があり、現在は主に mysql、MS SqlServer、oracle、PostGreSQL などのリレーショナル データベースをサポートしています。

2.2 データプロトタイプ分析

要件に応じて抽出できるエンティティには、ユーザー、ユーザー グループ、データ ソース、コード モジュール、メニューが含まれ、関係には権限とログが含まれます。エンティティと関係の意味は次のとおりです:

• User: DBuilder を使用するユーザーを示します。
ユーザー グループ: ユーザーのタイプ グループを表します。ユーザー タイプには、ゲスト、管理者、スーパー管理者の少なくとも 3 つのタイプが含まれている必要があります。
• データ ソース: DBuilder に含まれるデータベース構成を表します。データ ソースの構成には、データベースに接続するために必要な基本パラメーターが含まれます。
コード モジュール: DBuilder によって生成されたコード モジュールを表し、コード ファイルと構成を記述します。
• Menu: DBuilder の左側のメニュー項目を表します。
権限: 各コードモジュールに対するユーザーグループのさまざまな操作権限を示します。
• Log: 各コードモジュールに対するユーザーの CRUD アクセスログを表します。
エンティティと関係の ER 図は次のとおりです:
図 2-1 ER 図

2.3 原則要件

DBuilder は、高性能で可用性の高い CRUD ジェネレーターのセットとして作成される必要があります。このために、DBuilder の設計は次の原則に準拠する必要があります。

DBuilder はデータベース フィールドごとに正確で構成可能である必要があります。

ユーザーがこれに基づいて完全な WEB バックエンド アプリケーションを迅速に構築できるように、WEB バックエンド アプリケーションのプロトタイプが必要です。

DBuilder は、必要に応じて、キャッシュ、非同期、その他のテクノロジを使用して、リクエスト処理ロジックを削減し、ページの効率を向上させ、ユーザーの待ち時間を短縮する必要があります。

DBuilder には、美しく、簡潔で、直感的なユーザー インターフェイスが必要です。

DBuilder は多数の拡張インターフェイスを残し、ユーザーが二次開発を通じてより複雑な機能を迅速に実装できるようにする必要があります。

• 第 3 章 DBuilder システム設計
• 3.1 システムアーキテクチャ
• DBuilder には次の 2 つのコア コンポーネントがあります: コア CRUD モジュールと GModule。GModule は MVC コードと CRUD Config で構成され、GModule は DBuilder によって生成されます。コード。コア CRUD モジュールは CRUD 操作を実装し、GModule は拡張機能を実装します。以下の図は、これら 2 つのコンポーネントの構成と関係を示しています

図 3-1 概念とコンポーネント

以下は、図で設計された概念、コンポーネント、モジュールの関係、ビルドおよび CRUD プロセスの詳細な説明です。

3.1.1 コア CRUD モジュール

コア CRUD モジュールは、コア CRUD 操作を実装します。GModule MVC のコントローラーへのすべての CRUD リクエストは、最終的にコア CRUD モジュールに転送されて処理されます。 Core CRUD モジュールは、GModule が実装するための前処理インターフェイスと後処理インターフェイスをいくつか開きます。これらのインターフェイスは、モデル、コントローラー、ビューに反映されます。

コアCRUDモジュールには主に以下のファイルが含まれています

app/controllers/admin/AdminController.php

app/models/BaseModel.php

app/config/crud/admin.php app/views/admin/core/list.blade.php

app/views/admin/core/form.blade.php

• コア CRUD モジュールは GModule 設定を読み取り、実際の CRUD 操作を実装します。
• 3.1.2 Gモジュール
• GModule (生成されたモジュール) は、コア CRUD モジュール インターフェイス (MVC コード) を実装するだけでなく、独自の構成ファイル (CRUD 構成) も持ちます。
各 GModule は、メイン テーブルとしてのデータベース テーブルと、CRUD 関数を備えたコード ファイルのコレクション (対応する MVC + 構成コードを含む) を表します
• 。たとえば、DBuilder によって生成された GModule、メイン テーブルがコア データ ソース ユーザー テーブル、名前が User の場合、ユーザー GModule には次のコード ファイルが含まれている必要があります:
• コントローラー/UserController.php
• models/User.php
• views/user/_list.blade.php
• views/user/_form.blade.php
• views/user/view.blade.php
• config/crud/user.php

コード ファイルの名前は GModule の名前に依存するため、生成されたコード ファイルが競合しないようにするために、GModule の名前 (GModule Key、GModule Name) が、GModule の固有の識別子として使用されます。 Gモジュール。各GModuleの情報はデータベースに保存されます。新しい GModule 操作では、上記のすべてのコード ファイルが作成され、関連ファイルが更新され、GModule レコードがデータベースに挿入されます。 GModule の更新操作では、構成ファイルのみが更新されます。

GModule は、以下で説明する MVC コードと CRUD 構成コードで構成されます。

• MVC コード: 拡張インターフェイスの実装に使用されます。 CRUD リクエストは、まず GModule MVC のコントローラーにルーティングされる必要があります。また、GModule MVC は、Core CRUD モジュールの MVC コードと継承関係を持つ必要があります。
• CRUD 設定コード: GModule メイン テーブルへのパラメータの追加、削除、変更、クエリの設定を実装します。このファイルは app/config/crud/ ディレクトリに配置され、php 配列の形式で定義されます。これには、すべてのフィールドのフォーム、リスト、ビュー、リレーションシップなどのパラメーターの構成と、グローバル パラメーターの構成が含まれます。
GModule は特定のモジュールを表すのではなく、DBuilder によって生成されるか、開発者によって手動で作成されるモジュールのタイプを指します。主にコア CRUD モジュールのインターフェースを実装するために使用され、主に次の部分が含まれます
1) コントローラーインターフェイス
GModule モジュールのコントローラーが A、コア CRUD モジュールのコントローラーが B であるとすると、A は B を継承する必要があります。 CRUD リクエストは最初に A にルーティングされ、実際のハンドラーは B になります。 A は、B によって開かれた次のインターフェイスを実装します。
beforeListExcuteQuery(&querier): このインターフェイスは、List クエリがクエリを実行する前に呼び出され、渡されるパラメータはクエリ参照です。クエリを実行する前に特別なクエリ パラメータをバインドするために使用されます。
beforeList(&data): このインターフェイスは、リスト クエリが実行された後、リスト ビューがレンダリングされる前に呼び出されます。渡されるパラメーターはビュー パラメーター参照であり、クエリされたモデル コレクションが含まれます。これは、クエリされたモデル コレクションに対して後処理を実行するか、モジュール固有のパラメーターをリスト ビューにバインドするために使用されます。
beforeEditExcuteQuery(&querier): このインターフェイスは、モデル ククエリーが編集リクエストでクエリを実行する前に呼び出され、クエリー参照を渡します。モデルのクエリに必要な特別なパラメーターをバインドするために使用されます。
beforeEdit(&data): このインターフェイスは、Edit の Model クエリが実行された後、クエリによってクエリされたモデルを含むビューのパラメーター参照が渡される前に呼び出されます。レンダリング前の前処理に使用されます。
afterSave(&model): このインターフェイスは、Edit で編集内容を保存した後に呼び出されます。渡されるのはデータベースに保存されたモデルであり、最新のデータベース レコードが保持されます。モデルに対して複雑なポストカスケード処理を実行するために使用されます。
beforeView(data): このインターフェイスは、View リクエストで View クエリがクエリされ、ビュー パラメータの参照が渡された後に呼び出されます。ビュー表示の前処理に使用されます。
2) モデルインターフェース
GModule MVC コードのモデルも BaseModel から継承しており、BaseModel クラスによって開かれるいくつかのインターフェイスを実装することで拡張できます。
formatXXXAttribute(): このインターフェースは、特定のフィールドをフォーマットするために使用されます。この製品は Laravel に基づいていますが、Laravel には getXXXXAttribute() という同様のインターフェイスがすでにあります。ただし、このようなインターフェースの優先度はフィールドの優先度よりも高く、特殊なケースでは開発に不都合が生じるため、同様のインターフェースはフィールド自体の優先度よりも低い優先度で設計されます。
3) ビューインターフェイス
ビューの拡張インターフェイスは前の 2 つとは異なり、主にサブビューとビュー ブロックに反映されます。つまり、コア CURD モジュールのビューに基づいて、ビュー コンポーネントが拡張されます。デフォルトでは、Core CRUD MVC ビューは、ページを満たすテーブルまたはフォームを生成します。 View インターフェイスでは、ページ コンポーネントをテーブル上で上下左右に展開する機能が提供されます。
4) 構成
各 GModule は、メイン テーブルの各フィールドの GModule の設定パラメータとレイアウト パラメータを含む設定ファイルに対応します。
3.1.3 モジュール関係
CRUD リクエストは GModule のコントローラーにルーティングされます。GModule コードは Core CRUD MVC のオープン インターフェイスを実装し、Core CRUD モジュールは実際にデータベース上で CRUD 操作を実装します。 GModule に関連するメニュー、制御権限、操作ログの記録などを与えるために、各 GModule の情報をデータベース テーブルに記録する必要があります。いくつかの主要なモジュール間の関係を次の図に示します。
図 3-2 モジュールの関係
図 2-2 からわかるように、GModule 管理モジュールはユーザー設定に基づいて GModule A を生成し、ユーザーの CRUD リクエストが GModule A に到達すると、GModule はそのリクエストを処理のために Core CRUD に転送し、Core CRUD モジュールに転送します。次に、SQL を使用してデータベースに対して CRUD 操作を実行します。

3.1.4 ビルドと CRUD プロセス

DBuilder プロジェクトのソリューションは、実際の CRUD 操作をコア CRUD モジュールに渡して実行します。CRUD パラメーターは GET または POST リクエスト パラメーターと GModule 構成で構成されますが、GModule の MVC コードはコア CRUD の前処理またはオープン性のみを実装します。 MVC 後処理インターフェイス。

図 2-3 は、モジュールの生成と CRUD リクエストの処理を含む DBuilder のコア フローチャートです。図 2-4 は、SximoBuilder でのモジュールの生成と CRUD リクエストの処理のフローチャートです。

図 3-3 DBuilder コード生成と CRUD 処理プロセス

図 3-4 SximoBuilder コード生成と CRUD 処理プロセス

2 つを比較すると、2 つの最大の違いは、Sximo のように独立して実行できるモジュールごとに CRUD コードのセットを生成するのではなく、DBuilder が CRUD コードを再利用することであることがわかります。この利点は、モジュール CRUD MVC を介して前処理/後処理インターフェイスを実装することにより、再利用性が向上し、スケーラビリティが実現されることです。

3.2 コアデータソース

コア データ ソースは、DBuilder のデフォルトのデータ ソースです。そのタイプは mysql で、データベース名は dbuilder です。このセクションでは、「データ プロトタイプ分析」セクションに従って詳細なデータベース設計を実行します。プログラムのパフォーマンスを向上させるために、データ ソース情報はコード ファイル app/config/datasource.php に保存されます。ファイルの内容は次のとおりです。

'コア' =>

配列 (

'ドライバー' => 'mysql',

'ホスト' => 'ローカルホスト',

'データベース' => 'dbuilder',

'ユーザー名' => 'root',

'パスワード' => 'root',

'charset' => 'utf8',

'照合順序' => 'utf8_unicode_ci',

'プレフィックス' => '',

'編集' => false,

'ポート' => 3306,

)、

// その他のデータソース

);

コア データ ソースには次のデータ テーブルがあります:
1) d_menu テーブル: 背景の左側にあるツリー メニューを表し、クリックしてジャンプできる各メニュー項目はモジュールに関連付けられている必要があります。
表 3-1 Web バックエンドの左側のメニュー表