命名ルールを検討する - IM-LogicDesigner
IM-LogicDesignerのフロー定義、ユーザ定義およびルーティング定義で入力するIDと名称の命名方法についてのルールを、書式例と実際の入力例をもちいて紹介しています。
このページでは、「商品管理マスタ」というアプリケーションを作成する場合を想定して入力例を説明します。
慣れていないかたや、はじめてローコード開発をする際には、まずこのルールにしたがって開発をすることをおすすめします。一方で、ローコード開発の経験がある場合などには、このルールを参考に活用できる箇所をご自身のプロジェクトに反映していただくような利用を想定しています。
Accel Studioを使って開発することを前提に説明しています。アプリケーションIDやアプリケーション名はAccel Studioで作成・管理する単位のことです。
表記について
IDの命名方法について、書式例は以下のように表記します。{ }の囲みはその内容が定義済みのIDや処理名称、処理対象であることを示しています。これらを組み合わせてIDを命名します。
IDはスネークケース（snake_case）で命名します。{ }のリンク先で具体的な定義説明をしています。
実際の入力例は以下のように表記します。
- 入力例：
item_master_maintenance_register
{ }で囲んだ箇所の定義説明を以下のように表記します。
{application_id}
内容をitem_master_maintenanceとする説明を記載します。
{function}
内容をregisterとする説明を記載します。
事前準備
アプリケーション作成時に、アプリケーションIDとアプリケーション名を事前に決めておくことをおすすめします。
ほかのアプリケーションとの重複を避けることや、Accel Studioのアプリケーション管理＞リソースを追加で既存の資材を追加するときにどのアプリケーションで利用しているものなのかを判別しやすくするためです。
アプリケーションID
- 書式例：
{application_id} - 入力例：
item_master_maintenance
アプリケーション名
- 書式例：
{application_name} - 入力例：
商品管理
アプリケーションのIDと名称の定義ができたら、IM-LogicDesignerの各定義で入力する内容を検討していきます。
フロー定義
フロー定義を保存するときに入力する定義情報の例を紹介します。
フロー定義ID
- 書式例：
{application_id}_{function} - 入力例：
item_master_maintenance_register
フロー定義名
- 書式例：
{application_name} {処理名} - 入力例：
商品管理 登録処理
備考
書いておきたい説明があれば入力します。
{処理名}・{function}の決めかた
以下の手順で命名します。
- ロジックフローで定義する処理の概要を
{処理名}として命名する {処理名}をもとに{function}を命名する（参考：よくある処理の例）
よくある処理の例
| {処理名} | {function} |
|---|---|
| 登録処理 | register |
| 編集処理 | edit |
| 削除処理 | delete |
| 参照処理 | refer |
| 一覧参照処理 | list |
同一のアプリケーションで類似処理が複数ある場合には、それが区別できるようにするため、以下のようなルールを決めておくことをおすすめします。
例：処理対象のテーブルを示す文字列を前方に付けます。
faq_register
ユーザ定義
ユーザ定義を作成するときに入力する定義情報の例を紹介します。
ユーザ定義ID
- 書式例：
{application_id}_{kind}_{table}_{type}_{function} - 入力例：
item_master_maintenance_dml_insert
ユーザ定義IDはシステムで100文字以内の制約となっているため、長くなってしまう場合には一部略語を使うなどで対応してください。
ユーザ定義名
- 書式例：
{application_name} {処理名} - 入力例：
商品管理 INSERT
{kind}
ユーザ定義の種別から{kind}を命名します。
| ユーザ定義種別 | {kind} |
|---|---|
| SQL定義 | dml |
| REST定義 | rest |
| JavaScript定義 | js |
| DatabaseFetch定義 | db_fetch |
| CSV Fetch定義 | csv_fetch |
{table}
ユーザ定義の種別がSQLの場合、対象のテーブルから{table}を命名します。
- 入力例：
item_master、item_master_detail
命名例
- 区切り文字は
_アンダースコアにする（スネークケース） - SELECTで複数テーブルを結合している場合は、主要テーブル名とする
{type}
ユーザ定義の種別がSQLの場合、SQLの処理内容に応じて{type}を命名します。
| SQL処理 | {type} |
|---|---|
| 登録処理 | insert |
| 更新処理 | update |
| 削除処理 | delete |
| 取得処理 | get |
| 検索処理 | search |
| 検索件数の取得処理 | search_count |
{function}
処理内容がわかるような名称として{function}を命名します。
- 入力例：
parameter-check（パラメータチェック処理の場合）
ユーザ定義の種別がSQLの場合、_{kind}_{table}_{type}までのID定義で一意と判別できるなら_{function}は不要です。
{処理名}
処理内容がわかるような名称を付けます。
- 入力例：
パラメータチェック処理、検索用文字列生成、FAQ 登録処理、顧客 一覧取得
ルーティング定義
ルーティング定義を作成するときに入力する定義情報の例を紹介します。
| 入力項目 | 書式例 | 入力例 |
|---|---|---|
| ルーティング | {application_id}/{処理対象} | item_master_maintenance/messages |
| 認可URI | {ルーティング}-{HTTPメソッド} | item_master_maintenance/messages-GET |
{処理対象}
ルーティング（URL）は基本的に対象となるもの（リソース）を表すようにします。リソースが複数取り得る場合は、複数形で表記します。
命名例
- 範囲の大きなものから細かいものへの階層構造をスラッシュで区切る
- 例：
ticketsの中のmessagesが処理対象であれば、/tickets/messagesと命名する
- 例：
- 2つの単語で1つのものを表す場合は
-（ハイフン）区切りにしておく- 例：
/tickets/user-cds
- 例：
{HTTPメソッド}
リソースの操作はHTTPメソッド（GET、POST、PUT、DELETEなど）で表現します。
ただし、認可URIは一意である必要があるため末尾に-（ハイフン）区切りでHTTPメソッドを付けることで区別します。