我正在尝试在我的代码中实现以下出色的建议F# coding conventions page
https://learn.microsoft.com/en-us/dotnet/fsharp/style-guide/conventions https://learn.microsoft.com/en-us/dotnet/fsharp/style-guide/conventions.
这部分Use classes to contain values that have side effects特别有趣。它说
There are many times when initializing a value can have side effects, such as instantiating a context to a database or other remote resource. It is tempting to initialize such things in a module and use it in subsequent functions.
并提供了一个例子。然后它指出了这种做法的三个问题（由于篇幅有限，我省略了这些问题，但它们可以在链接的文章中看到）并建议使用一个简单的类来保存依赖项。
我想知道应该如何对待类型提供者？例如，如果我有以下代码，
[<Literal>]
let projDataPath = __SOURCE_DIRECTORY__ + @"\data\"
[<Literal>]
let configPath = projDataPath + "config.json"
type Cnfg = JsonProvider<Sample=configPath>
let config = Cnfg.Load(configPath)
使用类型提供程序来初始化值是否会遇到与值初始化相关的问题以及文章中描述的副作用？
换句话说，我应该将类型提供程序包装在类中吗？
通常，您根本不应该向使用者公开类型提供者的实例或其提供的类型。除了非 F# .NET 使用者可能出现的潜在互操作性问题之外，类型提供程序的实例通常表示应用程序正在管理的某些私有状态或资源的接口。作为一般规则，最好从消费者那里抽象出底层资源，并提供最适合问题领域的模型。
链接的文章特别警告不要捕获具有有限生命周期的类实例作为模块中的绑定，因为绑定是不可变的，并且实例在其生命周期结束时将变得无效。这相当于有一个DbContext或类似的实例static readonlyC# 类中的成员。它将由静态构造函数初始化，但永远不会改变，即使数据库连接关闭并且DbContext实例不再有用。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
