如何在 Visual Studio 中组织大型项目（>300 个类）的 F# 源？

Posted 2023-02-23

【中文标题】如何在 Visual Studio 中组织大型项目（>300 个类）的 F# 源？

【英文标题】：How to organize F# source of large project (>300 classes) in Visual Studio?

【发布时间】：2011-07-20 18:26:19

【问题描述】：

在 C# 中，您可以将文件放在与其命名空间对应的文件夹中，并在解决方案资源管理器中查看它们。

在 F# 中，我似乎必须将所有内容放在明确的明确排序列表中进行编译。当我达到约 300 个类的规模时，它变得有点混乱和杂乱无章，我开始羡慕 C#，并认为这可能是类型推断的代价。

有没有比拆分成多个程序集更好的选择？

从 F# 编译器源来看，它们采用的路线，但我有相当大的互连组件系统（控制器 - 视图模型 - 视图，> 300 个类）我想在一个程序集中，因为即使在接口级别也是循环依赖.

我应该忘记一个文件 - 一个类并创建一些大文件吗？（例如，在 F# 编译器中，您有几个 100kb 到 300kb 范围内的源文件，还有一些自动生成的大约 1Mb！） p>

您对大型 F# 项目有何经验？

【问题讨论】：

F# 正试图拯救你——让它来吧！ :-)

【参考方案1】：

您也可以拥有folders in F# projects。虽然有点麻烦，但是很管用。

我认为将多个类放在一个文件中是完全可以的，并且在 F# 中是惯用的如果这些类彼此密切相关。

我还没有参与过真正大型的 F# 项目，但我也对其他人的经验感兴趣。

【讨论】：

@MEMMark：谢谢。通过链接到 archive.org 来修复它。

同时支持开箱即用的文件夹（我相信来自 VS2017 15.3）。

【参考方案2】：

您提到“循环依赖”，需要明确的是，F# 永远不会让您在文件之间传播循环依赖。如果Foo 类型引用Bar 类型并且Bar 类型引用Foo 类型，那么Foo 和Bar 必须都定义在F# 中相同type ... and ... 组的相同文件中。

这里的问题是组织和导航，主要是关于工具。 VS 解决方案资源管理器显示文件列表；文件夹使您能够“折叠”文件组，从而可以更轻松地组织您的想法或在许多文件的“远距离”之间导航。但是对于导航，还有各种其他工具（转到定义，在当前项目中搜索文本，...）让您导航到例如一个特定的类定义。 （希望这些工具会在未来的版本中继续改进，特别是针对 F# 以及一般的 VS。）

无论如何，我坚信“相当大的互连组件系统（控制器 - 视图模型 - 视图，> 300 个类）”是一种代码味道。如果您无法将这些解开以具有架构分层，使得某些部分不依赖于其他部分（因此可以在 F# 的先前文件中“首先”定义），那么您面临的问题不仅仅是“如何组织你的 F# 代码”。我的观点也许是最好的表达here。

编辑（2018 年）：同时，这些工具得到了改进，除此之外，在过去的几个中添加了 go-to-definition、find-all-references、标识符的全局重命名、文件夹支持、文件重组等年。对于需要类之间相互引用的解决方案，引入了namespace rec 和module rec 以限制对type ... and ... 的需求。

【讨论】：

链接上的好帖子！是的，原始系统远没有分层，这让我很难将它移植到 F#！

依赖关系的这种线性排序是我不再将 C# 用于非平凡项目的主要原因之一（出于其他原因，我不会将它用于琐碎项目）。 F# 有效地防止了我在 C# 中经常犯的这个（非常昂贵的）错误。欣赏它需要一些时间，因此需要承担额外的工作，但随着软件的发展，它是无价的。

@Daniel 这听起来很有趣，但我并没有真正关注。您能否详细说明“依赖关系的线性排序”是什么意思？

一个源文件只能依赖在项目/编译顺序中出现在它前面的其他文件。