您會推薦什麼技術來爲Business Rules and Validation Application Block for .NET創建DSL？爲什麼？什麼技術用於爲規則引擎創建DSL？
框架的體系結構是由生產建立和驗證測試的。我只是想創建一個.NET處理器來將人類可讀的規則轉換爲已編譯的Rule實現。
，我所知道的選項是：.NET Boo
遺憾的是這些方法都沒有提供任何構建或多或少友好的用於編輯DSL的IDE，只要DSL語法（將會發展）。
任何想法或提示？
微軟的下一代應用程序開發平臺，代號爲Oslo
使人們更容易寫下來的方式，對問題域，他們在工作的意義
奧斯陸似乎由名爲「Quadrant」的可視化設計工具，名爲「M」的建模語言和存儲規則的「Oslo」存儲庫（SQL Server數據庫）組成。
所以如果我正確地閱讀了一些東西，你可以在M中定義一個建模語言，使用Quadrant來使用你自己的建模語言來定義和編輯你的驗證規則，然後編寫一個利用奧斯陸知識庫的應用程序， .NET的規則和驗證應用程序塊。
如果您想要創建一個友好的IDE來編輯DSL，請使IDE完全圖形化，並編譯爲.NET對象（或使用類似IronPython作爲粘合語言）。
如果規則很簡單，可以用圖形方式實現整個規則結構。 如果規則足夠複雜，「人的可讀性」就成爲不可能的目標。無論採用哪種方式，如果創建中間代碼的一組.NET類或IronPython對象足夠不夠「人類可讀」，那麼很可能是，您想要的東西比語法更能防僞。這就是說，如果你只是想創建一個程序員可以用來創建業務規則的簡單語言，可以隨意使用上述任何一種語言，並且使語法足夠簡單，而不需要Visual Studio的IDE。
業務規則的圖形化語言不是一個好主意。我會避免它商業規則有很多如果檢查和循環，它們不可視化。
用描述業務規則的文本語言你會好得多。
要獲得編輯代碼phenomenial的用戶體驗，您需要：
良好的錯誤恢復的能力，使您從合成不完整的構建體有效地確定programer意圖。這對於實施智慧至關重要。
執行增量重新編譯的能力使您能夠對用戶編輯做出有效的後臺編譯。
獲得良好錯誤恢復的最簡單方法是手動編寫解析器。通過這種方式，您可以使用任何數量的預測或algrorithmic規則來確定在出現語法錯誤時應採取的措施。
當您使用解析器生成器來創建解析器時，您在處理語法錯誤時失去了很多靈活性。這種靈活性使得良好的智力經驗與療法之間的差異成爲可能。所以，我建議你用遞歸下降手工編寫它。 1）正確地將語義分析分解爲階段（對於像C＃這樣的東西，這將是：首先構造命名空間和類型符號，然後使用語句解析，然後解析基礎課程等）。 2）構建一個相感知依賴圖 3）算法用於處理依賴圖，並且響應於用戶無效的它的部分的能力編輯
對於全flegged編程語言，實施重新編譯可以得到真的很棘手。就你而言，因爲你正在描述業務規則，所以對你來說可能更簡單（或者如果編譯足夠快，你甚至可能不需要它）。
所以，我會先從解析器開始，然後在它上面構建智能。
如果你能避免VS集成，我會的。整合到VS需要很多管道，互操作可能會導致頭痛。有幾家公司出售Windows窗體編輯器控件，可以解決您的解析器問題。這比VS更容易集成。
循環並不像向非程序員解釋那樣難以形成圖形。我已經用圖形語言編寫了一個循環繁瑣的代碼，它們並沒有你聲音那麼糟糕。例如Envox CDP。 對於非編碼器，解決意味着沒有語法錯誤。 – user54650 2009-02-13 14:23:21
另一個可能有趣的選擇是使用F＃語句。
引用語言允許您將程序的一部分視爲數據，因此您可以獲取AST，分析它並將其轉換爲其他語言或以非標準方式執行。結合F＃的靈活性，您應該能夠表達許多事情，因此您必須開發一個用於描述規則的內部F＃DSL /組合器庫以及F＃語句的譯碼器/解釋器來運行它們。
不知道一個bussines規則可能看起來怎麼樣，但是你可以寫這樣的事情：
let rule = <@
if (exists customer having validEmail) then success
else require whatever
@>
我寫了一個介紹，這個話題在我的博客。不幸的是，F＃CTP發生了一些重大變化，我還沒有更新源代碼，但它應該給你一個很好的想法，這種方法的可能性有哪些限制。
DSL的一個很好的例子是F＃的單元測試framewrok：
[編輯] 只是爲了澄清我爲什麼想S可以是一個好方法：
[/編輯]
希望這有助於！
我會使用Boo，我認爲它是目前DSL創建最靈活的工具之一。關於這個問題有一個very good book。 Ayende's和Rodrigo's博客也是很好的啓發。
關於IDE，您可以擴展SharpDevelop，看看this。
JetBrains公司Meta Programming System
您可以自定義語言編輯器等方面的限制對於任何新的語言，使這些DSL的工作變得非常簡單。不熟悉傳統編程的領域專家可以使用領域特定的語言，使用領域特定的術語輕鬆地在MPS中工作。
我對此很陌生，但OMeta似乎是開發DSL的理想工具。周圍似乎沒有IDE，但好消息是人們可以在OMeta中編寫的「規則」非常易讀。 （它處理左遞歸，這是非常酷。）
目前有至少在Javascript（我非常興奮）和Python，也許其他人的OMeta實現。至於C＃，Jeff Moser正在編寫一個，您可以在his blog上閱讀，並在CodePlex處查看。 祝你好運。
構建DSL接縫的標準工具是ANTLR - 它是一個功能強大的詞法分析器/分析器生成器，它具有許多用於編譯器輸出的目標語言。它具有C＃，Java，C/C++，Python等後端（請參閱code generation targets列表），並允許您輕鬆地將自定義代碼注入目標語言的編譯器。
還有一個非常強大的IDE（ANTLRWorks）和大量的文檔。 （請查閱Terrence Parr的The Defenitive ANTLR Reference，ANTLR的作者）有關誰還用它的參考資料，請參閱Testimonlals頁面。
您仍然需要自己完成IDE的大部分工作，但考慮到您將從ANTLR獲得穩健的編譯器框架，它應該會容易得多。這應該是這裏發佈的大多數解決方案的情況...
我目前正在使用與ANTLR編寫的編譯器預處理我們自己的DSL到C/C++輸出，我非常滿意。足夠的廣告，你應該爲自己嘗試:)玩得開心！
噓+ OMeta = Boo.OMeta.Parser
目前解析器正在開發中，但它已經可以用於創建複雜的外部DSL。 OMeta是一個功能強大的工具，它使程序員能夠輕鬆實現詞法分析器和解析器。 Boo的可擴展編譯器管道結構允許用Boo.OMeta.Parser替換標準的Boo.Parser。它可以用於以幾乎任何類型的語法擴展Boo語法。 示例可以找到here。
我的項目meta#正試圖解決這個問題。
a「to」too much in the topic？ – Svish 2009-02-16 07:30:22
謝謝，錯過了那一個。 – 2009-02-16 14:07:12