¿Cómo organizar F# fuente de proyectos grandes (> 300 clases) en Visual Studio?

Question

En C# puede colocar archivos en carpetas correspondientes a sus espacios de nombres y verlos en el explorador de soluciones.

En f# parece que tengo que poner todo en una lista simple específicamente ordenada para la compilación. Cuando llego a la escala de ~ 300 de clases, se vuelve un poco confuso y desorganizado y empiezo a envidiar a C# y creo que probablemente sea el precio de la inferencia de tipo.

¿Hay mejores opciones que dividirse en varios ensamblajes?

A juzgar por F#, la fuente del compilador es la ruta que han tomado, pero tengo un sistema bastante grande de componentes interconectados (controlador - ViewModel - View,> 300 clases) Quiero estar en un ensamblaje debido a dependencias circulares incluso a nivel de interfaces.

¿Debo olvidarme de un archivo: una clase y crear algunos archivos enormes? (por ejemplo, el compilador F# tiene varios archivos de origen en el rango de 100kb a 300kb y algunos autos generados alrededor de 1 MB!)

¿Cuál es su experiencia con grandes proyectos de F#?

Answer 1

Usted menciona "dependencias circulares", para ser claras, F# nunca le permitirá difundir dependencias circulares en todos los archivos. Si tipo Foo se refiere al tipo Bar y escribir Bar se refiere al tipo Foo, después Foo y Bar ambos deben definirse en el mismo archivo en el mismo type ... and ... grupo en f#.

El problema aquí es uno de la organización y la navegación, que se trata principalmente de las herramientas. El VS Solution Explorer muestra una lista de archivos; Las carpetas le permiten 'colapsar' grupos de archivos que pueden facilitar la organización de sus pensamientos o navegar a través de 'grandes distancias' de muchos archivos. Sin embargo, para la navegación hay varias otras herramientas (vaya a la definición, busque texto en el proyecto actual, ...) para permitirle navegar a EG una definición de clase particular. (Esperemos que estas herramientas continúen mejorando para F# en particular, así como VS en general, en futuras versiones).

En cualquier caso, creo firmemente que un "sistema bastante grande de componentes interconectados (controlador - ViewModel - View,> 300 clases)" es un olor a código. Si no puede desenredarlos para que tengan una estratificación arquetectura de tal manera que haya porciones que no dependan de otras porciones (y por lo tanto podrían definirse 'primero' en un archivo anterior en f#), entonces tiene problemas mayores que "cómo para organizar su código F# ". Mi opinión obstinada es quizás mejor expresada aquí.

EDIT (2018): Mientras tanto, las herramientas han mejorado, entre muchas otras cosas, se han agregado referencias de referencia, referencias globales de identificadores, soporte de carpetas, reorganización de archivos, etc. Para soluciones que requieren referencias mutuas entre clases, namespace rec y module rec han sido introducidos para limitar la necesidad de type ... and ....

Answer 2

Tu puedes tener Carpetas en proyectos F#, también. Es un poco engorroso, pero funciona.

Creo que poner varias clases en un archivo está perfectamente bien e idiomático en f# si Las clases están estrechamente relacionadas entre sí.

Todavía no he trabajado con proyectos F# realmente grandes, pero también estoy interesado en la experiencia de los demás.