Следует ли обернуть поставщиков типов, содержащих значения, которые имеют побочные эффекты внутри класса?

Question

Я пытаюсь реализовать в своем коде отличный совет на странице F# coding conventions

https://docs.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)

, использующий провайдер типа для инициализации значения, является предметом проблем, связанных с инициализацией значения с побочными эффектами, описанными в статье?

Другими словами, должен ли я обернуть поставщика типов внутри класса?

Answer 1

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

Связанная статья специально предупреждает против захвата экземпляров классов с конечным жизненным циклом в качестве привязок.в модуле, потому что привязки являются неизменными и экземпляр станет недействительным, когда закончится его жизненный цикл.Это было бы эквивалентно наличию DbContext или аналогичного экземпляра в качестве члена static readonly в классе C #.Он будет инициализирован статическим конструктором, но никогда не сможет измениться, даже если соединение с базой данных будет закрыто и экземпляр DbContext больше не будет полезен.