Alf*_*a07 21 f# assemblies code-organization visual-studio c#-to-f#
在C#中,您可以将文件放在与其命名空间相对应的文件夹中,并在解决方案资源管理器中查看它们.
在F#中,似乎我必须将所有内容放在简单有序的列表中进行编译.当我达到~300级的规模时,它会让人感到有些困惑和混乱,我开始羡慕C#,并认为它可能是类型推断的代价.
有没有比拆分成几个组件更好的选择？
由F#编译器的源来看它的路线,他们已经采取,但我有互联组件(控制器视图,> 300类 - - 视图模型)的相当大的系统,我想是因为在循环依赖的一个组件,即使在接口水平.
我应该忘记一个文件 - 一个类并创建一些巨大的文件？(例如,在F#编译器中,您有几个100kb到300kb范围内的源文件,并且有些自动生成1Mb左右!)
您对大型F#项目的体验是什么？
Bri*_*ian 14
你提到"循环依赖",要清楚,F#永远不会让你在文件中传播循环依赖.如果类型Foo是指输入Bar和类型Bar是指键入Foo,然后Foo和Bar必须同时在相同的文件中相同的定义type ... and ...在F#组.
这里的问题是组织和导航,主要是关于工具.VS解决方案资源管理器显示文件列表; 通过文件夹,您可以"折叠"文件组,这样可以更轻松地整理您的想法或浏览许多文件的"远距离".但是,对于导航,还有各种其他工具(转到定义,在当前项目中搜索文本,...),以便您导航到例如特定的类定义.(希望这些工具在未来的版本中,特别是对于F#以及VS一般都会继续改进.)
无论如何,我坚信"相当大的互连组件系统(Controller - ViewModel - View,> 300类)"是一种代码味道.如果你不能解开这些,以便有一个archetectural分层,使得有些部分不依赖于其他部分(因此可以在F#中的先前文件中"首先"定义),那么你遇到的问题不仅仅是"如何整理你的F#代码".我的观点也许在这里表达得最好.
编辑(2018年):与此同时,工具已经改进,在许多其他方面,在过去几年中增加了定义,查找全部参考,标识符的全局重命名,文件夹支持,文件重组等.对于需要在类之间进行相互引用的解决方案,namespace rec并且module rec已经引入以限制需求type ... and ....