Cejuno Framework内部処理の流れとコアアーキテクチャ概要 (3/3)

 / 
  • HOME > 
  • 全ての記事 > 
  • Cejuno Framework内部処理の流れとコアアーキテクチャ概要

目次

  1. ページファイル
  2. Cejuno Frameworkの内部処理フロー（概要）
  3. Cejuno Frameworkの「核」Entity
    1. Property要素
    2. Propertyごとに「DB」「フォーム」「一覧表示」を一括定義
    3. Confirm項目や結合項目もXMLだけで表現
    4. マスタ連動や複合フォームも一元化
    5. ViewConfigによる画面単位の設定
    6. EntityコンフィグがCejunoの「核」である理由
    7. 他フレームワークとの違い
  4. DataAccessコンフィグ
    1. Environment単位でデータソースを切り替えられる構造
    2. DataSourceNameはEntityコンフィグと1対1で紐づく
    3. Adapter体系の思想
    4. 呼び出し側から見ると“1つのクラスしかない”
    5. Taskとの連携：フレームワーク利用者は「何も意識しない」
    6. 他フレームワークとの違い
 

DataAccessコンフィグ

Cejuno Framework全体の「美しい構造の連鎖」を見せる上で、まさに“土台の中の土台” にあたる部分、データアクセスを紹介します。

Cejuno Frameworkでは、Entityで定義された情報をどこから取得し、どこへ保存するのか──
この「データアクセスの源泉」を DataAccessConfig.xml により定義します。

このXMLは、環境ごとに使用するデータストアと接続設定を記述する“データアクセスの入口”であり、Cejuno Frameworkの自動化されたWorkflow・Task処理の背後で、透明に動作する仕組みを支えています。

4-1. DataAccessコンフィグ

1 :
2 :
3 :
4 :
5 :
6 :
7 :
8 :
9 :
10 :
11 :
12 :
13 :
14 :
15 :
16 :
17 :
18 :
19 :
20 :
21 :
22 :
23 :
24 :
25 : 
<?xml version="1.0" encoding="UTF-8"?>
<DataAccessConfig>
	<Environment Type="Local">
		<DataSource Name="DefaultDB" Type="MySQL" URL="cejuno.com" Encoding="UTF-8">
			<Parameter Key="Host" Value="localhost" />
			<Parameter Key="Port" Value="3306" />
			<Parameter Key="User" Value="root" />
			<Parameter Key="Password" Value="cejuno" />
			<Parameter Key="Charset" Value="utf8" />
		</DataSource>
		<DataSource Name="FileDB" Type="XML" URL="system/resource/db/xml" Encoding="UTF-8">
		</DataSource>
	</Environment>
	<Environment Type="Server">
		<DataSource Name="DefaultDB" Type="MySQL" URL="cejuno.com" Encoding="UTF-8">
			<Parameter Key="Host" Value="mysql.db.cejuno.com" />
			<Parameter Key="Port" Value="3306" />
			<Parameter Key="User" Value="emdo" />
			<Parameter Key="Password" Value="cejuno" />
			<Parameter Key="Charset" Value="utf8" />
		</DataSource>
		<DataSource Name="FileDB" Type="XML" URL="system/resource/db/xml" Encoding="UTF-8">
		</DataSource>
	</Environment>
</DataAccessConfig>
 

Environment単位でデータソースを切り替えられる構造

  • Environment Type="Local"
  • Environment Type="Server"
のように、ローカル開発環境と本番サーバーを明確に分け、それぞれに複数のDataSource（例：MySQL、XMLファイルDBなど）を設定できます。

これにより、

  • どの環境でも同じEntity定義
  • 同じWorkflow
  • 同じTask
で動作しつつ、裏側のデータ実体だけが切り替わるという柔軟性を実現しています。

Environment自体の選択もenv.iniの設定から自動的に切り替わる仕組みとなります。

 

DataSourceNameはEntityコンフィグと1対1で紐づく

Entityコンフィグ側の最上位エレメントのDataSourceName属性の値が、DataAccessコンフィグのDataSourceエレメントのName属性と一致することで、

  • どのDBに接続するか
  • どのAdapterを利用するか
が自動で決まります。

つまり、Entityの保存先はXMLの1行で切り替わるということです。

 

Adapter体系の思想

Cejuno Frameworkのデータアクセス層は、以下のようなAdapterの階層で抽象化されています。

4-2. DataAdapterクラス体系

1 :
2 :
3 :
4 :
5 :
6 :
7 :
8 :
9 :
10 :
11 :
12 :
13 :
14 : 
DataAdapter
    ├─ DatabaseAdapter
    │      ├─ MySQLAdapter
    │      ├─ PostgreSQLAdapter
    │      └─ OracleAdapter
    │              :
    │              :
    │
    └─ DataFileAdapter
           ├─ CSVAdapter
           ├─ XMLAdapter
           └─ PropertiesAdapter
                    :
                    :

上位のDataAdapterは“データにアクセスするための抽象的なインターフェース”であり、その下に各データベースやファイル形式ごとの具体的Adapterが存在します。

 

呼び出し側から見ると“1つのクラスしかない”

開発者・フレームワーク利用者はAdapterの種類を意識する必要はありません。

なぜなら、アクセス操作はすべてDataAccessManagerが一元管理しているためです。

どのAdapterが使われるか？Entity経由でDataAdapterFactoryが自動で決定します。

$adapter = DataAdapterFactory::parse($entity -> getDataSourceName());

つまり、Entityが

  • MySQLを指せばMySQLAdapter
    • XMLファイルを指せばXMLAdapter
      • CSVならCSVAdapter
      というように、Entityが“データのありか”を宣言するだけで、Cejuno Frameworkは最適な経路を自動選択する仕組みです。

      また、DataAccessManagerに対して使用するメソッドは基本的に以下の5つだけです。

      getEntity();
      getEntityList();
      insertEntity();
      updateEntity();
      deleteEntity();

      これらのメソッドは、背後で適切なAdapterを呼び出し、Entityを自動的に取得・保存・更新できるようになっています。

 

Taskとの連携：フレームワーク利用者は「何も意識しない」

実際には、Workflow内のTask──
例えば EntityGetter、EntityUpdater、EntityRegisterなどが適切なタイミングで呼び出され、

DataAccessManager → 適切なAdapter → Entity

という処理がすべて自動的に実行されます。

結果として、

  • SQLを書く必要はない
  • DB接続の処理も不要
  • トランザクションもTask側が制御可能
  • XML編集だけで保存・更新が可能
となり、利用者は“Entityを扱っているだけでデータ操作が完了する”という体験を得られます。

これがCejuno Frameworkの思想である

  • 「実装のためのコード」ではなく
  • 「構造のための定義」だけを書く世界
を根本から支えています。

 

他フレームワークとの違い

Cejuno Frameworkのデータアクセスに関するAdapter体系とEntity体系が完全に対応している設計思想は、一般的なフレームワークでは“ほぼ再現できない設計思想”です。

通常のフレームワークは、

  • DB変更＝コード変更
  • 接続先追加＝Repository追加
  • SQL or ORMの調整が山ほど発生
という構造的欠陥があります。

しかしCejuno Frameworkでは、XMLを1行変えるだけでデータアクセス層全体が切り替わる。

そして極めつけは、Taskが自動的にDataAccessManagerを呼び、利用者は“データアクセスという概念そのものを意識しなくてよくなる”という革命的な発想が大きな違いと言えます。

Previous Page <<
Cejuno Frameworkの「核」Entity

ページナビ

  • HOME > 
  • 全ての記事 > 
  • Cejuno Framework内部処理の流れとコアアーキテクチャ概要