降低 API 流畅度的最佳方法?
我正在扩展 Fluent NHibernate,以便更好地与 F# 一起使用(即引用支持),并希望获得一些关于降低 API 流畅度的反馈。 F# 要求使用返回值,除非它们是单位类型。 因此,这最终以“|>ignore”终止每一行:
type ProductMap() as m = inherit QClassMap<Product>() do
let x = Unchecked.defaultof<Product>
m.Id <@ x.Id @> |> ignore
m.Map <@ x.Name @> |> ignore
m.Map <@ x.Price @> |> ignore
(m.HasManyToMany <@ seq x.StoresStockedIn @>)
.Cascade.All()
.Inverse()
.WithTableName("StoreProduct") |> ignore
我的第一反应是向基类添加更多方法,以便它们返回单位。 例如,“IdI”和“MapI”:
...
m.IdI <@ x.Id @>
m.MapI <@ x.Name @>
m.MapI <@ x.Price @>
...
但这需要到处都有特定的重载,并且长链仍然需要 |> 。 忽略。 我还考虑过使用 Done 属性扩展对象:
(m.Id <@ x.Id @>).Done
(m.Map <@ x.Name @>).Done
(m.Map <@ x.Price @>).Done
(m.HasManyToMany <@ seq x.StoresStockedIn @>)
.Cascade.All()
.Inverse()
.WithTableName("StoreProduct").Done
您觉得怎么样?
I'm extending Fluent NHibernate for better use with F# (namely, quotation support), and want some feedback on de-fluenting the API. F# requires that return values be used, unless they are type unit. So this ends up terminating every line with "|> ignore":
type ProductMap() as m = inherit QClassMap<Product>() do
let x = Unchecked.defaultof<Product>
m.Id <@ x.Id @> |> ignore
m.Map <@ x.Name @> |> ignore
m.Map <@ x.Price @> |> ignore
(m.HasManyToMany <@ seq x.StoresStockedIn @>)
.Cascade.All()
.Inverse()
.WithTableName("StoreProduct") |> ignore
My first reaction was to add more methods to the base class so they return unit. For instance, "IdI" and "MapI":
...
m.IdI <@ x.Id @>
m.MapI <@ x.Name @>
m.MapI <@ x.Price @>
...
But that requires specific overloads here and there, and long chains are still going to need a |> Ignore. I also considered extending object with a Done property:
(m.Id <@ x.Id @>).Done
(m.Map <@ x.Name @>).Done
(m.Map <@ x.Price @>).Done
(m.HasManyToMany <@ seq x.StoresStockedIn @>)
.Cascade.All()
.Inverse()
.WithTableName("StoreProduct").Done
What do you think?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
恕我直言,更好的方法是从头开始思考 F#(例如函数管道、柯里化、组合器),而不是包装流利的 nhibernate,但是使用流利的 nhibernate 所使用的内容生成映射。 即构建一个F#专用的“并行流畅nhibernate”。
我最近发布了关于类似的问题Windsor 在 F# 中的流畅界面。 我的结论是,为 C# / VB.NET 构建的许多 DSL / 流畅接口将在 F# 中中断,因此我认为最好构建适合 F# 方式的特定流畅接口。
IMHO a better approach would be to start from scratch thinking in F# (e.g function piping, currying, combinators) instead of wrapping fluent nhibernate, but using what fluent nhibernate has used to generate the mappings. That is, building a "parallel fluent nhibernate" for exclusive use of F#.
I've recently posted about a similar issue with Windsor's fluent interface in F#. My conclusion is that many DSLs / fluent interfaces built for C# / VB.NET will break in F# so I think it's best to build specific fluent interfaces that suit the F# way.