現在、私が取り組んでいるプロジェクトには、(外部の影響により) 完全に修正されたモデルがないため、モデルを柔軟に記述できるようにしたいと考えています。現在、それらはアプリケーションの 3 つの異なるレイヤー (db、web api、およびクライアント) にわたって複製されており、それぞれに同様のロジック (つまり、検証) があります。
モデルファイル（Rubyなど）を作成し、そのモデルを必要なc＃ファイルに変換できるアプローチがあるかどうか疑問に思っていました。現在、私はどの段階でも変更される可能性のある多くの定型コードを書いているようですが、この生成されたアプローチにより、より重要なことに集中することができます。
このようなもの、私がこれを行うことができるDSL /言語の推奨事項はありますか?また、このようなことに関する経験はありますか?
これはANTLRで簡単に実行できます。出力が十分に類似している場合は、単純にテキスト テンプレート メカニズムを使用できます。それ以外の場合は、トラバースする抽象構文ツリーを生成できます。
部分クラスと部分メソッドを使用して、カスタム コードに影響を与えずにコードを再生成できるシステムを見てきました。「ルール エンジン」は、Visio 状態図から完全に生成されたものです。これは基本的に貧弱なワークフローですが、変更は非常に簡単です。Viso ダイアグラムは XML にエクスポートされ、powershell と T4 を使用して読み込まれ、クラスが生成されました。
上記の例は、外部 DSL のものです。IE は、アプリケーションが実行されるプログラミング言語の外部にあります。一方、プログラミング言語で実装および使用される内部 DSL を作成することもできます。
これとCode-Magazine のDSLS に関する以前の記事は非常に優れています。
上記のリンクでは、Neal Ford が流暢なインターフェイスを使用して C# で内部 DSL を作成する方法を示しています。
彼がまだ言及していないことの 1 つは、この属性 [EditorBrowsable(EditorBrowsableState.Never)] をメソッドに付けて、intellisense に表示されないようにすることができるということです。これは、DSL のユーザーからクラスの非 DSL メソッドを非表示にできることを意味し、流暢な API をより見つけやすくします。
TDD を使用した IoC コンテナーの作成に関するDaniel Cazzulinoによるこのビデオ シリーズで、流暢なインターフェイスがライブで作成されているのを見ることができます。
外部 DSLに関しては、考えられるコード生成を使用するのではなく、直接実行できる外部 DSL を作成できるという点で非常に強力なOslo (現時点では CTP)のオプションもあります。それはまったく DSL ではありません。
あなたは正しい軌道に乗っていると思います。
このような状況で私が通常行うことは、自分のニーズを捉える単純な言語を設計し、そのための LL1 (再帰降下) パーサーを作成することです。
言語に重要な C# 構文が含まれている必要がある場合は、それを引用するか、認識できる角かっこで囲み、出力コードに渡すことができます。
解析ツリー構造を生成し、そこから 3 つの異なる種類のコードを生成するか、3 つの値を持つモード変数を使用してその場でコードを生成するか、3 つの値に同時にコードを書き込むことができます。異なる出力ファイル。
それを行う方法は複数あります。パーサーを書くのが怖い場合 (一部のプログラマーはそうです)、SO の他の場所に多くの助けがあります。