GeneXus認定ジュニアアナリストの問題を無料で10問体験

GeneXusでは「何を(What)」実現したいかをナレッジベース(Knowledge Base、KB)に宣言的に記述すると、「どう作るか(How)」にあたるデータベースのテーブル定義・SQL文・画面のCRUDロジックはGeneXus自身が自動的に生成する。 ・開発者が書くもの: Transactionの属性・レベル・ルール(Rule)などの「仕様」 ・GeneXus任せになるもの: SQL文、画面の内部ロジック、テーブル構造の細部 手続き型(Procedural)やオブジェクト指向(Object-Oriented)は実装方法そのものを記述するスタイルであり、GeneXusの宣言的アプローチとは対照的。「何を書けば、どう作るかはGeneXusが決める」がこの思想の要点。

KBは、業務で扱う対象(顧客・注文・商品など)とその関連・ルールを、特定の言語やDBMSに依存しない形で蓄積する、GeneXus開発の中心的な器。 ・KBには多種類のオブジェクト(Transaction、Procedure等)が格納される ・同一のKBから、複数の生成言語・DBMS向けに(Environmentの設定次第で)アプリケーションを生成できる ・一般的なIDEの「プロジェクト/ソリューションファイル」やソース管理の「リポジトリ」とは別概念であり、業務知識そのものを保持する点がGeneXus固有の特徴

目的別に主要オブジェクトを整理する: ・Transaction — データ構造(属性・レベル)+CRUD画面。GeneXusの中核 ・Procedure — 画面を持たないバッチ/処理オブジェクト。テーブル更新や複雑な処理ロジックに使う ・Web Panel — 対話的なUI画面。自由なレイアウトの検索・入力画面に使うが、自身ではテーブル構造を定義しない ・Data Provider — 階層的な構造化データ(SDT)を読み込んで返すことに特化。画面なし・読み込み専用 ・SDT(Structured Data Type) — テーブルに縛られない階層的なデータ構造の型定義。Data Providerの戻り値やWebサービスの入出力に使う ・Query — 属性・条件・集計を宣言的に設定するだけでSQLを自動生成する、レポート・グリッド向けのデータ取得オブジェクト ・Theme — 画面の色・フォント・余白などの見た目をまとめて管理するデザインオブジェクト 「画面を持つか」「テーブル構造を持つか」「データを返すだけか」の3軸で整理すると迷いにくい。

・画面あり+テーブル構造あり: Transaction ・画面あり+テーブル構造なし: Web Panel ・画面なし+処理/データ受け渡しが目的: Procedure、Data Provider ・画面なし+見た目(スタイル)の定義が目的: Theme 「画面がない」オブジェクトは複数あるが、目的まで見て区別することが重要(Procedure/Data Providerは処理・データ授受、Themeはスタイル定義)。