将F#和Caliburn.Micro结合使用

Question

据我所知，Caliburn.Micro以基于约定的方式为WPF项目做了大量的自动布线和管道处理；使用MVVM。

问:在C#中是否有Caliburn.Micro的特定部件；哪些部分使用了一些C#专用的特性？Caliburn.Micro的哪些部分不能与F#代码一起使用？使用F#会带来什么损失？

Answer 1

不幸的是，Caliburn.Micro和F#没有很好地结合在一起。

例如，Caliburn.Micro在约定匹配期间(通过反射)将视图视为常规类，这对于C#来说是正确的-视图是部分类。

F#不支持部分类，视图仅为XAML文件。这意味着Caliburn.Micro无法解决这些问题。这也意味着在引导程序中连接IoC容器会有问题，因为它将无法创建视图--至少没有手动注册Application.LoadComponent等等。

设置引导程序也很痛苦，因为您必须在App.xaml中指定密钥，但无论出于什么原因，该键与类不匹配。Bootstrapper<T>还将bool useApplication = true作为缺省值传递给BootstrapperBase --而F#有不同的问题，这取决于是否设置了该标志，不幸的是，我不记得细节了。这是因为在F#中，您自己将入口点连接到应用程序，而构建Caliburn.Micro是为了自动拦截该步骤。引起冲突..。

如果您通过完全覆盖约定解析机制和将任何IoC容器弯曲到您的意愿来工作，那么您将拥有更多的能力。在我看来，目前有太多的摩擦。

就我个人而言，我使用C#建立了Caliburn.Micro应用程序的核心基础，并在F#中完成了“真正的工作”。或者，我认为您甚至可以在单独的项目中使用F#编写视图模型，在C#项目中使用视图，然后您只需调整引导程序中约定查找的工作方式。不过，我不太确定这种方法，所以你的里程可能会有所不同，而且要谨慎行事。

Answer 2

这是个不错的问题。如果你坚持到底，一定要让我们知道它的进展情况。我在看卡利伯恩的一个附带项目，但我在这方面没有取得多大进展。

因此，要开始，你可能已经偶然发现了：

NotifyOfPropertyChange的Lambda表达超载

引发PropertyChanged事件的基本方法有两个重写。一个以属性名称作为字符串，另一个接受lambda表达式。后者使用一个巧妙的技巧/丑陋的黑客从表达式的主体中提取属性名。这在C#中给出了一个好的、简洁的语法，编译器在一定程度上检查了这个语法：

public string SomeProp
{
    get { return someField; }
    set
    {
        someField = value;
        NotifyOfPropertyChange(() => SomeProp);
    }
}

但这并不能很好地转化为F#。你的选择是要么回到字符串1，要么用引号来加糖。我用过这样的方法：

let notify<'a> (notifier: PropertyChangedBase) (expr: Expr<'a>) =
    let name =
        match expr with
        | PropertyGet (_, pi, _) -> pi.Name
        | _ -> failwith "Can't get property name to notify"
    notifier.NotifyOfPropertyChange(name)

它被称为这样的：

member this.SomeProp 
    with get () = 
        someField
    and set(value) = 
        someField <- value
        notify this <@ this.SomeProp @>

我相信您可以更进一步，将它滚到构建在PropertyChangedBase之上的自己的PropertyChangedBase类中。