Вы упомянули "циклические зависимости", чтобы быть ясным, F # никогда не позволит вам распространять циклические зависимости по файлам. Если тип Foo относится к типу Bar, а тип Bar относится к типу Foo, тогда Foo и Bar должны быть определены в одном файле в одной и той же группе type ... and ... в F #.
Проблема здесь связана с организацией и навигацией, в основном с инструментами. Обозреватель решений VS отображает список файлов; папки позволяют вам «сворачивать» группы файлов, что облегчает организацию ваших мыслей или навигацию по «огромным расстояниям» многих файлов. Однако для навигации существуют различные другие инструменты (Перейти к определению, поиск текста в текущем проекте, ...), чтобы вы могли перейти, например, к. определенное определение класса. (Надеемся, что эти инструменты будут улучшаться для F # в частности, а также для VS в целом в будущих версиях.)
В любом случае, я твердо верю, что «довольно большая система взаимосвязанных компонентов (Controller - ViewModel - View,> 300 классов)» - это запах кода. Если вы не можете распутать их, чтобы иметь архетектурное наслоение, так что есть части, которые не зависят от других частей (и, таким образом, могут быть определены «первыми» в предыдущем файле в F #), тогда у вас есть большие проблемы, чем просто «как» организовать свой код F # ". Мое убежденное мнение, пожалуй, лучше всего выражено здесь .
РЕДАКТИРОВАТЬ (2018): между тем, в последние несколько лет были добавлены инструменты, среди которых: переход к определению, поиск всех ссылок, глобальное переименование идентификаторов, поддержка папок, реорганизация файлов и т. Д. года. Для решений, которые требуют взаимных ссылок между классами, были введены namespace rec и module rec, чтобы ограничить потребность в type ... and ....