tutorial - ¿Cómo organizar la fuente F#de proyectos grandes(> 300 clases) en Visual Studio?
visual studio code español (2)
En C # puede colocar los 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 la lista ordenada específicamente ordenada para la compilación. Cuando llego a una escala de ~ 300 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 tipos.
¿Hay mejores opciones que dividir a varios conjuntos?
A juzgar por la fuente del compilador de F # 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 las dependencias circulares, incluso al nivel de las interfaces.
¿Debo olvidarme de un archivo, una clase y crear algunos archivos enormes? (Por ejemplo, en el compilador F #, tiene varios archivos de origen en el rango de 100 kb a 300 kb y algunos se generan automáticamente en torno a 1 mb).
¿Cuál es tu experiencia con grandes proyectos de F #?
También puede tener carpetas en proyectos F # . Es un poco engorroso, pero funciona.
Creo que poner varias clases en un archivo es perfectamente correcto 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 otros.
Menciona "dependencias circulares", para ser claros, F # nunca le permitirá distribuir dependencias circulares entre archivos. Si el tipo Foo refiere al tipo de Bar y el tipo de Bar refiere al tipo Foo , entonces Foo y Bar deben definirse en el mismo archivo del mismo type ... and ... grupo en F #.
El problema aquí es uno de organización y navegación, que es principalmente sobre las herramientas. El explorador de soluciones VS muestra una lista de archivos; las carpetas le permiten "colapsar" grupos de archivos, lo que puede facilitar la organización de sus ideas o navegar por las "grandes distancias" de muchos archivos. Sin embargo, para la navegación hay otras herramientas (Ir a la definición, buscar texto en el proyecto actual, ...) para permitirle navegar, por ejemplo, a una definición de clase particular. (Esperamos 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 de código. Si no puede desentrañar estos para tener una capa de arquitectura tal que hay partes que no dependen de otras (y por lo tanto podrían definirse ''primero'' en un archivo anterior en F #), entonces tiene problemas más grandes que solo "cómo para organizar su código F # ". Mi opinión opinada es quizás mejor expresada here .
EDIT (2018): mientras tanto, las herramientas han mejorado, entre otras muchas cosas, se han agregado las referencias, encontrar referencias a todos, el cambio de nombre global de los identificadores, el soporte de carpetas, la reorganización de archivos, etc., en los últimos años. Para soluciones que requieren referencias mutuas entre clases, se han introducido namespace rec y module rec para limitar la necesidad de type ... and ...