Как организовать исходный код F # большого проекта (›300 классов) в Visual Studio?

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

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

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

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

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

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


person Alfa07    schedule 22.03.2011    source источник
comment
F # пытается вас спасти - пусть! :-)   -  person Daniel    schedule 22.03.2011


Ответы (2)


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

Проблема здесь в организации и навигации, и в основном это касается инструментов. В обозревателе решений VS отображается список файлов; Папки позволяют «сворачивать» группы файлов, что упрощает систематизацию мыслей или перемещение на «огромных расстояниях» множества файлов. Однако для навигации существуют различные другие инструменты («Перейти к определению», поиск текста в текущем проекте, ...), позволяющие перейти, например, к конкретное определение класса. (Надеюсь, в будущих выпусках эти инструменты будут продолжать улучшаться для F # в частности, а также для VS в целом.)

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

РЕДАКТИРОВАТЬ (2018): тем временем инструменты улучшились, среди прочего, за последние несколько лет были добавлены переход к определению, поиск всех ссылок, глобальное переименование идентификаторов, поддержка папок, реорганизация файлов и т. Д. Для решений, требующих взаимных ссылок между классами, были введены namespace rec и module rec, чтобы ограничить потребность в type ... and ....

person Brian    schedule 22.03.2011
comment
Хороший пост по ссылке! Да, исходная система далека от многоуровневой, и поэтому мне трудно портировать ее на F #! - person Alfa07; 22.03.2011
comment
Этот линейный порядок зависимостей - одна из основных причин, по которой я больше не буду использовать C # для нетривиальных проектов (я не использую его для тривиальных проектов по другим причинам). F # эффективно предотвращает эту (очень дорогую) ошибку, которую я так часто совершал в C #. Потребовалось некоторое время, чтобы оценить это и, следовательно, перенести необходимую дополнительную работу, но это бесценно по мере роста программного обеспечения. - person Daniel; 22.03.2011
comment
@Daniel Звучит интересно, но я не совсем понимаю. Не могли бы вы подробнее рассказать, что означает линейное упорядочение зависимостей? - person MEMark; 23.10.2013
comment
Исходный файл может зависеть только от других файлов, которые появляются перед ним в порядке проекта / компиляции. - person Daniel; 23.10.2013

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

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

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

person wmeyer    schedule 22.03.2011
comment
@MEMMark: Спасибо. Исправлено путем ссылки на archive.org. - person wmeyer; 23.10.2013
comment
Между тем, папки поддерживаются из коробки (я полагаю, из VS2017 15.3). - person Abel; 28.03.2018