F #: Лучший способ разобраться в API?

Question

Я расширяю 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

Что ты думаешь?

Answer 1

ИМХО, лучшим подходом было бы начать с нуля , думая в F # (например, функции трубопроводов, карри, комбинаторы) вместо обертки беглого nhibernate, , но , используя то, что использовал беглый nhibernate генерировать отображения. То есть создание "параллельного свободного nhibernate" для исключительного использования F #.

Я недавно опубликовал о похожей проблеме с плавным интерфейсом Виндзора в F #. Я пришел к выводу, что многие DSL / свободные интерфейсы, созданные для C # / VB.NET, сломаются в F #, поэтому я думаю, что лучше создавать конкретные свободные интерфейсы, подходящие для F #.