あなたが求めていることを実行することは確かに可能であり、いくつかの異なるアプローチがありますが、要件をより深く検討することをお勧めします.
Ruby 以外の言語では、他の人が同様のメタモデリング CMS フレームワークを設計および構築するのを手伝いました。最初のものは 1999 年に完成しました。モデルとモデル間の関係をブラウザから直接作成するための完全な Web GUI です。当時これを行わなければならなかった理由は、私たちが使用していた基盤となるプラットフォームでは、モデルの作成と MVC の実行がかなり難しく、フレームワーク コードと GUI ツールの両方で開発者を支援する必要があったためです。
言語としての Ruby は、内部ドメイン固有言語に適しています。Rails は内部 DSL を頻繁に使用します。特にActiveModel
. このため、多くの場合、Rails モデルの基本的なコードを記述する方が、他の (より高い) レベルの抽象化を使用するよりもはるかに簡単です。特に GUI ツールは、ラウンドトリップが原因で、優れたモデルを構築する場合に対処するのが非常に困難です。コードを手動で変更し、その変更を GUI に反映できるようにする必要があります。難しい問題です。
それでもなお、GUI ベースのメタモデリング アプローチを使用したい場合は、次の 2 つの主要な方法から選択できます。
- パラメータ化された RoR メタモデルの構築
- 特定の RoR モデルの生成
あなたの質問の言い回しから、あなたは(2)に興味があるようです。その場合、これを行うための標準的なアプローチが 2 つあります。解釈またはコンパイルです。解釈する場合は、モデルを記述するための DSL を作成し、その実行によって Rails 環境でモデルがインスタンス化されます。(Ruby では、クラスはそれらを定義するコードを実行することによって定義されるため、これはすべて完全に正常です。) コンパイルするよりも、お気に入りの永続化フレームワークを使用する標準 RoR モデルをコード生成します。問題は、コードをどこに保管するかということです。ディスクに書き込んで読み込むことができます。たとえば、データベースに保存することもできます。どちらの場合も、sourcifyなどの gem を参照することをお勧めします。
余談ですが、このタイプのシステムを構築することを選択した場合は、NoSql ドキュメント指向の永続化メカニズムを使用することを強くお勧めします。たとえば、Mongoid などを使用する MongoDB です。その理由は、Rails が提供する SQL スキーマ管理のサポートが限定的であり、ワークフローの自動化が (基本的な移行を超えて) 少ないためです。人々に GUI を与えると、より頻繁にスキーマをいじる可能性が高くなります。したがって、スキーマの移行の問題に対処する必要があります。ドキュメント データベースを使用すると、これが少し簡単になります (問題の処理を怠惰な方法でコードに任せるという点で、問題をパンパンにすることもあります)。通常、リレーショナル データベースではそれができません。事前にスキーマを移行する作業が必要であり、システムに多くの要件が追加され、開発者のワークフロー全体に摩擦が生じます。
幸運を!