Business Rules and Validation Application Block for .NETの DSL を作成するには、どのテクノロジをお勧めしますか? なぜ？
フレームワークのアーキテクチャは、プロダクションによって確立され、実証テストされています。人間が読めるルールをコンパイル済みのルール実装に変換する .NET プロセッサを作成したいだけです。
私が知っているオプションは次のとおりです。
残念ながら、これらのアプローチのいずれも、DSL 構文 (進化する可能性があります) を考えると、DSL を編集するための多かれ少なかれフレンドリーな IDE を構築するものを提供しません。
アイデアやヒントはありますか？
Microsoft の次世代アプリケーション開発プラットフォーム、コードネームOslo (現 Delve)
人々が取り組んでいる問題領域にとって意味のある方法で物事を書き留めることを容易にする
Oslo は、"Quadrant" という名前のビジュアル デザイン ツール、"M" という名前のモデリング言語、およびルールを格納する "Oslo" リポジトリ (SQL Server データベース) で構成されているようです。
したがって、私の理解が正しければ、M でモデリング言語を定義し、Quadrant を使用して、独自のモデリング言語を使用して検証ルールを定義および編集し、Oslo リポジトリを利用するアプリケーションを作成して、ビジネス ルールと検証アプリケーションを生成することができます。 .NET のブロック。
もう 1 つの興味深い代替方法は、F# の引用符を使用することです。
引用符を使用すると、プログラムの一部をデータとして扱うことができるため、AST を取得して分析し、他の言語に翻訳したり、非標準的な方法で実行したりできます。F# の柔軟性と合わせて、多くのことを表現できるはずです。そのため、ルールを記述するための内部 F# DSL/コンビネーター ライブラリと、それらを実行するための F# クォーテーション用のトランスレーター/インタープリターを開発する必要があります。
ビジネスルールがどのように見えるかはわかりませんが、次のように書くことができます:
let rule = <@
if (exists customer having validEmail) then success
else require whatever
@>
このトピックの紹介をブログに書きました。残念ながら、F# CTP にはいくつかの大きな変更があり、ソース コードはまだ更新していませんが、このアプローチの可能性と制限を理解していただけるはずです。
DSL の良い例は、F# ユニット テスト フレームワークです。
[編集] なぜこれが良いアプローチだと思うのかを明確にするために：
[/編集]
お役に立てれば！
ビジネスルールのグラフィカル言語は良い考えではありません。私はそれを避けたいと思います。ビジネスルールには多くのifチェックとループがあり、それはうまく視覚化されません。
ビジネスルールを説明するためのテキスト言語を使用する方がはるかに優れています。
コードを編集するための驚異的なユーザーエクスペリエンスを得るには、次のものが必要です。
優れたエラー回復により、構文的に不完全な構成からプログラマーの意図を効果的に判断できます。これは、インテリジェンスを実装するために重要です。
インクリメンタル再コンパイルを実行する機能により、ユーザーの編集に応じて効率的なバックグラウンドコンパイルを実行できます。
優れたエラー回復を実現する最も簡単な方法は、パーサーを手動で作成することです。そうすれば、構文エラーが存在する場合に何をすべきかを理解するために、任意の量の先読みまたはアルゴリズム規則を使用できます。
パーサジェネレータを使用してパーサを作成すると、構文エラーを処理する際の柔軟性が大幅に低下します。その柔軟性は、優れたインテリジェンス体験と安っぽい体験の違いを生み出します。したがって、再帰下降を使用して手書きで記述することをお勧めします。
効率的な再コンパイルを実装するには、次のことができる必要があります。1）セマンティック分析をフェーズに適切に分割する（C＃のようなものの場合、最初に名前空間とタイプシンボルを作成し、次にステートメントを使用して解決し、次に基本クラスを解決するなど）。2）位相認識依存関係グラフを作成する機能3）依存関係グラフを処理し、ユーザーの編集に応じてその一部を無効化するためのアルゴリズム
本格的なプログラミング言語の場合、再コンパイルの実装は非常に難しい場合があります。あなたの場合、あなたはビジネスルールを記述しているので、それはあなたにとって非常に単純かもしれません（またはコンパイルが十分に速いならあなたはそれを必要としないかもしれません）。
それで、私はパーサーから始めて、それからその上にインテリジェンスを構築します。
VS統合を回避できれば、私はそうします。VSに統合するには、多くの配管が必要であり、相互運用により頭痛が発生する可能性があります。パーサーを接続するWindowsフォームエディターコントロールを販売している会社がいくつかあります。これは、VSよりもはるかに簡単に統合できます。
DSLのシームをANTLRとして構築するための標準ツール-これは、コンパイラ出力用の多くのターゲット言語を備えた強力なレクサー/パーサージェネレーターです。C＃、Java、C / C ++、Pythonなどのバックエンドがあり（コード生成ターゲットリストを参照）、ターゲット言語でカスタムコードをコンパイラに簡単に挿入できます。
非常に強力なIDE（ANTLRWorks）と多くのドキュメントもあります。（ ANTLRの作者であるTerrenceParrからのDefenitiveANTLRリファレンスをチェックしてください）他に誰がそれを使用するかについてのリファレンスについては、証言のページを参照してください。
IDEの配管のほとんどは自分で行う必要がありますが、ANTLRから得られる堅牢なコンパイラフレームワークを考えると、はるかに簡単なはずです。これは、ここに投稿されたほとんどのソリューションに当てはまるはずです...
私は現在、ANTLRで記述されたコンパイラを使用して、独自のDSLからC / C ++への出力を前処理しており、非常に満足しています。広告は十分にあるので、自分で試してみてください:)楽しんでください！
JetBrainsメタ プログラミング システム
カスタム言語エディターやその他の制約を新しい言語に対して定義できるため、これらの DSL の操作が非常に簡単になります。従来のプログラミングに慣れていないドメインの専門家は、ドメイン固有の用語を使用して、ドメイン固有の言語を使用して MPS で簡単に作業できます。
私はまだ慣れていませんが、OMetaは DSL を開発するための理想的なツールのようです。それに関する IDE はないようですが、OMeta に記述できる「ルール」は非常に読みやすいという朗報があります。(そして、非常にクールな左再帰を扱います。)
現在、少なくとも Javascript (私にとって非常に興味深い) と Python で OMeta の実装があり、おそらく他の実装もあります。C# に関しては、Jeff Moserが取り組んでいる C# の 1 つについては、彼のブログで読むことができ、 CodePlexで確認できます。幸運を。
私のプロジェクトmeta#は、この問題を解決しようとしています。
DSL を編集する使いやすい IDE を作成する場合は、IDE を完全にグラフィカルにし、.NET オブジェクトにコンパイルします (または、IronPython などをグルー言語として使用します)。
ルールが単純であれば、ルール構造全体をグラフィカルに実装できます。ルールが複雑すぎると、「人間が読みやすい」という目標は実現不可能になります。
いずれにせよ、中間コードを作成する .NET クラスまたは IronPython オブジェクトのセットが十分に「人間が読める」ものではない場合、おそらく、文法よりもダミー証明が必要になるでしょう。
とはいえ、プログラマーがビジネス ルールを作成するために使用できる単純な言語を作成したい場合は、上記のいずれかを自由に使用して、Visual Studio の IDE を必要としないように構文を最小限に抑えてください。