Как организовать F # источник большого проекта (> 300 классов) в Visual Studio?

В С# вы можете помещать файлы в папки, соответствующие их пространствам имен, и просматривать их в обозревателе решений.

В F # мне кажется, что я должен поместить все в простой упорядоченный список для компиляции. Когда я получаю до масштабов ~ 300 классов, он становится немного запутанным и дезорганизованным, и я начинаю завидовать С# и думаю, что, вероятно, это цена за вывод типа.

Есть ли лучшие варианты, чем разделение на несколько сборок?

Судя по компилятору F #, его маршрут, который они взяли, но у меня довольно большая система взаимосвязанных компонентов (Controller - ViewModel - View, > 300 классов), я хочу быть в одной сборке из-за круговых зависимостей даже на уровне интерфейсов,

Должен ли я забыть об одном файле - один класс и создать огромные файлы? (например, в компиляторе F # у вас есть несколько исходных файлов в диапазоне от 100 кб до 300 кб, а некоторые автоматически генерируются вокруг 1 Мб!)

Каков ваш опыт работы с большими проектами F #?

Ответы

Ответ 1

Вы указываете "круговые зависимости", чтобы быть ясным, F # никогда не позволит вам распространять круговые зависимости между файлами. Если тип Foo относится к типу Bar, а тип Bar относится к типу Foo, то Foo и Bar должны быть определены в том же файле в той же группе type ... and ... в F #.

Здесь речь идет о организации и навигации, в основном о инструментах. Исследователь VS-решений отображает список файлов; папки позволяют вам "сворачивать" группы файлов, которые упрощают организацию ваших мыслей или перемещаются по "большим расстояниям" многих файлов. Однако для навигации существуют различные другие инструменты (Go To Definition, поиск текста в текущем проекте,...), чтобы вы могли перейти к, например, определение конкретного класса. (Надеемся, что эти инструменты будут продолжать улучшаться для F # в частности, а также VS вообще, в будущих выпусках.)

В любом случае я твердо уверен, что "довольно большая система взаимосвязанных компонентов (Controller - ViewModel - View, > 300 классов)" - это запах кода. Если вы не можете распутать их, чтобы иметь архетектное расслоение, так что есть части, которые не зависят от других частей (и таким образом могут быть определены "сначала" в предыдущем файле в F #), тогда у вас есть больше проблем, чем просто "как для организации вашего кода F #". Мое упрямое мнение, пожалуй, лучше всего выражено здесь.

Ответ 2

У вас могут быть папки в проектах F #. Это немного громоздко, но оно работает.

Я думаю, что добавление нескольких классов в один файл совершенно нормально и идиоматично в F # , если классы тесно связаны друг с другом.

Я еще не работал с действительно большими проектами F #, но меня тоже интересует опыт других.