在 C# 中，您可以将文件放在与其命名空间对应的文件夹中，并在解决方案资源管理器中查看它们。
在 F# 中，我似乎必须将所有内容放在明确的明确排序列表中进行编译。当我达到约 300 个类的规模时，它变得有点混乱和杂乱无章，我开始羡慕 C#，并认为这可能是类型推断的代价。
有没有比拆分成多个程序集更好的选择？
从 F# 编译器源来看，它们采用的路线，但我有相当大的互连组件系统（控制器 - 视图模型 - 视图，> 300 个类）我想在一个程序集中，因为即使在接口级别也是循环依赖.
我应该忘记一个文件 - 一个类并创建一些大文件吗？（例如，在 F# 编译器中，您有几个 100kb 到 300kb 范围内的源文件，还有一些自动生成的大约 1Mb！） p>
您对大型 F# 项目有何经验？
【问题讨论】：
标签： visual-studio f# assemblies code-organization c#-to-f#
您也可以拥有folders in F# projects。虽然有点麻烦，但是很管用。
我认为将多个类放在一个文件中是完全可以的，并且在 F# 中是惯用的如果这些类彼此密切相关。
我还没有参与过真正大型的 F# 项目，但我也对其他人的经验感兴趣。
【讨论】：
您提到“循环依赖”，需要明确的是，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 ... 的需求。
【讨论】：