在 C# 中，您可以将文件放在与其命名空间相对应的文件夹中，并在解决方案资源管理器中查看它们。
在 F# 中，似乎我必须将所有内容放在明确的特定排序列表中进行编译。当我达到约 300 个类的规模时，它变得有点困惑和杂乱无章，我开始羡慕 C#，并认为这可能是类型推断的代价。
有比拆分为多个程序集更好的选择吗？
从 F# 编译器源代码来看，它采用了它们所采用的路线，但我有相当大的互连组件系统( Controller - View 模型 - View ，> 300 个类)我想在一个程序集中，因为即使在接口(interface)级别也是循环依赖。
我应该忘记一个文件 - 一个类并创建一些大文件吗？ (例如，在 F# 编译器中，您有几个 100kb 到 300kb 范围内的源文件，并且一些自动生成的文件在 1Mb 左右!)
您对大型 F# 项目有何经验？
最佳答案
您提到“循环依赖”，需要明确的是，F# 永远不会让您在文件之间传播循环依赖。如果输入 Foo指类型Bar并输入 Bar指类型Foo ，然后 Foo和 Bar必须在同一个文件中的同一个 type ... and ... 中定义F# 中的组。
这里的问题是组织和导航之一，主要是关于工具。 VS 解决方案资源管理器显示文件列表；文件夹使您能够“折叠”文件组，从而可以更轻松地组织您的想法或在许多文件的“远距离”之间导航。但是对于导航，还有各种其他工具(转到定义，在当前项目中搜索文本，...)让您导航到例如一个特定的类定义。 (希望这些工具在 future 的版本中将继续改进特别是 F# 以及一般的 VS。)
无论如何，我坚信“相当大的互连组件系统( Controller - View 模型 - View ，> 300 个类)”是一种代码味道。如果您无法将这些解开以具有架构分层，使得某些部分不依赖于其他部分(因此可以在 F# 的先前文件中“首先”定义)，那么您面临的问题不仅仅是“如何组织你的 F# 代码”。我的固执己见也许是最好的表达here .
编辑(2018 年):与此同时，这些工具得到了改进，除其他外，在过去几年中添加了转到定义、查找所有引用、标识符的全局重命名、文件夹支持、文件重组等。对于需要类之间相互引用的解决方案，namespace rec和 module rec已引入以限制对 type ... and ... 的需求.
关于visual-studio - 如何在 Visual Studio 中组织大型项目(>300 个类)的 F# 源代码？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5396465/