fluent interfaces 与DSLs的区别
because you have a lot of freedomwhen you define the language for the DSL, but fluent interfaces have to work withinthe limits of a typically rigid language to work
fluent interfaces的例子
newFluentTask("warn if website is down")
.Every(TimeSpan.FromMinutes(3) )
.StartingFrom(DateTime.Now )
.When(() => new WebSite("http://example.org").IsNotResponding )
.Execute(() => Notify("admin@example.org", "server down!"))
.Schedule();
或
Schedule.Task( "warn if website is down" ).
Repeat.Every( 3 ).Minutes.
Starting(DateTime.Now ).
If(Web.Site( "http://example.org" ).IsNotResponding() ).
Notify( "admin@example.org", "Site down!" );
等价的DSL的例子
task "warn if website is down":
every 3.Minutes()
starting now
whenWebSite("http://example.org").IsNotResponding
then:
notify "admin@example.org", "server down!"
DSL code doesn’t have to work to make the compiler happy, nordoes it have the ugly lambda declaration in the middle of the code or all the syntacticbaggage (parentheses)
Fluent interfaces tend to be harder to scale than DSLs.
关于该问题的参考
http://www.midnightcoder.net/Blog/viewpost.rails?postId=38
如何选择
Fluent interfaces are usually useful only during the development process.
If domainexperts are going to be the users, you’ll probably want a full-blown DSL in place,because that will make it easier to work with the concepts of the domain. If the targetaudience is programmers, and the expected usage is during normal development, afluent interface would be appropriate.
the issue of the syntax that you want to use. DSLs aremore expressive.
语法
One of the major reasons to build a DSL is to hide the complexities of the implementation with a language that makes sense to the domain experts.
Ø ƒ An imperative DSL specifies a list of steps to execute (to output text using a tem
plating DSL, for example). With this style, you specify what should happen.
Ø ƒA declarative DSL is a specification of a goal. This specification is then executed
by the supporting infrastructure. With this style, you specify the intended result.
Imperative DSLs usually specify what to do,and declarative DSLs specify what you want done.
不同形式的DSL语法例子：
SQL and regular expressions are examples of declarativeDSLs. They both describe what you want done, but not howto do it.
Build scripts are great example of imperative DSLs.It doesn’t matter what build engine you use (NAnt, Rake,Make), the build script lists actions that need to be executedin a specified order.
There are also hybrid DSLs, which are amix of the two. They are DSLs that specify what you wantdone, but they also have some explicit actions to execute.
A more declarative approach to specifying rules
applyDiscount 5.percent:
whenUser.IsPreferred and Order.TotalCost> 1000
suggestPreferred:
when not User.IsPreferred and Order.TotalCost> 1000
freeShipping:
whenOrder.TotalCost> 500 and User.IsNotPreferred
whenOrder.TotalCost> 1000 and User.IsPreferred
DSL组成
A typical DSL is usually split into several distinct parts:
ƒ Syntax—This is the core language or the syntax extensions that you create.
ƒ API—This is the API used in the DSL; it is usually builtpecifically to support the DSL and its needs.
ƒModel—This is the existing code base we reuse in our DSL (usually using afacade). The difference between the API and the model is that the model usually represents the notions in our application (such as Customer, Discount, and so on), whereas the API focuses on providing the DSL with convenient ways toaccess and manipulate the model.
ƒ Engine—This is the runtime engine that executes the DSL and processes itsresults.
参考图书： DSLs in Boo Domain-Specific Languages in .NET