如何在 Visual Studio 中组织大型项目(> 300 个类)的 F# 源代码? [英] How to organize F# source of large project (>300 classes) in Visual Studio?
问题描述
在 C# 中，您可以将文件放在与其命名空间相对应的文件夹中，并在解决方案资源管理器中查看.
在 F# 中，似乎我必须将所有内容都放在简单的专门排序的列表中以进行编译.当我达到大约 300 个类的规模时，它会变得有点混乱和混乱，我开始羡慕 C#，并认为这可能是类型推断的代价.
是否有比拆分为多个程序集更好的选择?
从 F# 编译器源来看，它们采用的路径是它们所采用的路线，但我有相当大的互连组件系统(控制器 - ViewModel - 视图，> 300 个类)我想在一个程序集中，因为即使在接口级别也是循环依赖.
我应该忘记一个文件 - 一个类并创建一些大文件吗?(例如，在 F# 编译器中，您有几个 100kb 到 300kb 范围内的源文件和一些自动生成的大约 1Mb！)>
您对大型 F# 项目的体验如何?
你提到了循环依赖"，需要明确的是，F# 永远不会让你跨文件传播循环依赖.如果 Foo 类型指的是 Bar 类型，而 Bar 类型指的是 Foo 类型，那么 Foocode> 和 Bar 必须在 F# 中相同的 type ... and ... 组中的同一文件中定义.
这里的问题是组织和导航之一，主要是关于工具.VS 解决方案资源管理器显示文件列表；文件夹使您能够折叠"文件组，这可以更轻松地组织您的想法或在许多文件的远距离"中导航.但是对于导航，还有其他各种工具(转到定义，在当前项目中搜索文本，...)让您导航到例如特定的类定义.(希望这些工具将在未来版本中继续针对 F# 以及总体上的 VS 进行改进.)
无论如何，我坚信相当大的互连组件系统(Controller - ViewModel - View，> 300 个类)"是一种代码味道.如果您无法解开这些以具有架构分层，使得某些部分不依赖于其他部分(因此可以在 F# 的先前文件中首先"定义)，那么您将面临更大的问题，而不仅仅是如何组织您的 F# 代码".我的观点也许是最好的表达这里.
编辑(2018 年):同时，工具得到了改进，其中包括转到定义、查找所有引用、标识符的全局重命名、文件夹支持、文件重组等在过去的几年中已添加年.对于需要类之间相互引用的解决方案，引入了namespace rec 和module rec 以限制对type ... and ....
In C# you can put files in folders corresponding to their namespaces and view them in the Solution explorer.
In F# it seems I have to put everything in plain specifically ordered list for compilation. When I get to scale of ~300 of classes it gets a bit confusing and disorganized and I start to envy C# and think that probably it is the price for type inference.
Are there better options than splitting to several assemblies?
Judging by F# compiler source its the route they have taken but I have pretty large system of interconnected components (Controller - ViewModel - View, > 300 classes) I want to be in one assembly because of circular dependencies even at level of interfaces.
Should I forget about one file - one class and create some huge files? (e.g. in F# compiler you have several source files in 100kb to 300kb range and some auto generated around 1Mb!)
What is your experience with large F# projects?
You mention "circular dependencies", to be clear, F# will never let you spread circular dependencies across files. If type Foo refers to type Bar and type Bar refers to type Foo, then Foo and Bar must both be defined in the same file in the same type ... and ... group in F#.
The issue here is one of organization and navigation, that is mostly about the tooling. The VS solution explorer displays a list of files; folders enable you to 'collapse' groups of files which can make it easier to organize your thoughts or navigate across 'great distances' of many files. However for navigation there are various other tools (Go To Definition, search for text in the current project, ...) to let you navigate to e.g. a particular class definition. (Hopefully these tools will continue to improve for F# in particular, as well as VS in general, in future releases.)
In any case, I firmly believe that a "pretty large system of interconnected components (Controller - ViewModel - View, > 300 classes)" is a code smell. If you can't untangle these to have an archetectural layering such that there are portions that do not depend on other portions (and thus could be defined 'first' in a prior file in F#), then you have bigger problems than just "how to organize your F# code". My opinionated view is perhaps best-expressed here.
EDIT (2018): meanwhile, the tools have improved, among many other things, go-to-definition, find-all-references, global renaming of identifiers, folder support, file reorganization etc have been added in the past few years. For solutions that require mutual references between classes, namespace rec and module rec have been introduced to limit the need for type ... and ....
这篇关于如何在 Visual Studio 中组织大型项目(> 300 个类)的 F# 源代码?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
