Интегрировать F # в существующее приложение .Net

Question

Я заинтересован в использовании сильных сторон F # в области параллелизма в существующее приложение .Net.То есть я хотел бы учесть компонент F #, который обрабатывал бы только параллельные сообщения моего приложения, оставляя большую часть моего существующего проекта .Net без изменений.Существующее приложение будет вызывать компонент F #.

1) Желательна ли эта архитектура?2) Если да, то есть ли примеры, демонстрирующие подход к этой схеме с использованием передового опыта?

Спасибо,

Джон

Answer 1

1) Рекомендуется ли эта архитектура?

Конечно, это не плохой подход:)

Главное, о чем я бы беспокоился, это каквлияет на других членов команды - нужно ли им изучать новый язык для добавления новых функций или устранения проблем?Если остальной части вашей команды неудобно использовать ее, вы можете рассмотреть возможность поиска или создания своей собственной библиотеки передачи сообщений в C #.

2) Если да, есть ли какие-нибудь примеры там?которые демонстрируют лучший подход к этому проекту?

Мне нравится постоянно смешивать F # и C # в моих проектах.По моему опыту, использование C # dll из F # намного проще, чем наоборот.Большинство конструкций, которые мы хотели бы использовать в F #, выглядят забавно и не интуитивно понятно в C #.Просто для забавы, посмотрите, как в Reflector отображается следующий код:

let f x y z = x(y z)
let (|A|B|C|) x =
    match x with
    | 1 -> A
    | 2 -> B
    | x -> C x
type whatever = X | Y | Z of int

Функции карри отображаются как FSharpFunc, активные шаблоны имеют смешное имя и тип возврата, объединения имеют очень странный набор членов,и т.д. Они выглядят странно в C #, поэтому вы, скорее всего, захотите выставить фасад с более приятной сигнатурой C # для любых модулей, которые вы ожидаете использовать публично.Например:

module CSharpFacade =
    let f(x : System.Func<_, _>, y : System.Func<_, _>, z) = f (fun param -> x.Invoke(param)) (fun param -> y.Invoke(param)) z

    [<AbstractClass>]
    type Whatever() =
        inherit obj()
        abstract member Map : unit -> whatever
    type X() =
        inherit Whatever()
        override this.Map() = whatever.X
    type Y() =
        inherit Whatever()
        override this.Map() = whatever.Y
    type Z(value : int) =
        inherit Whatever()
        member this.Value = value
        override this.Map() = whatever.Z(value)

Так что довольно просто заключить F # делегаты и объединения для C #.Я действительно не хочу показывать активный шаблон, он будет внутренним, если не требуется иное.

И вы можете захотеть обернуть некоторые / нет типы во что-то более приемлемое, например, используя Nullable<someValueType> на местеOption<someValueType> и отображение null ссылочного типа на None, где это необходимо, и т. д.

Answer 2

Это, безусловно, правильный подход к проблеме. Это на самом деле ничем не отличается от выделения какой-либо части вашего приложения в отдельную библиотеку классов. Любые лучшие практики с этим процессом должны применяться к языку новой DLL, являющейся F #.

Бесстыдная Самостоятельная Акция ниже:

Если вы ищете примеры из реальной жизни, в которых используется этот подход, один проект, на который стоит обратить внимание, это проект VsVim . Это эмулятор Vim для Visual Studio, который использует F # для своей основной функциональности, но использует C # для интеграции в Visual Studio.

Может содержать не все лучшие практики, но содержит примеры работы с некоторыми конструкциями F #, которые могут быть странными для использования в таких языках, как C # или VB.Net. В частности варианты и дискриминационные союзы.