En un anterior artículo ya vimos la estructura de archivos en feature oriented, una estructura de código especialmente útil para WPF, Xamarin, DotNet Maui y otros frameworks de plataforma de DotNet. En este artículo veremos más en detalle la función y responsabilidad que se le da a cada tipo de archivo individualmente. Aunque en feature oriented agrupemos los objetos por funcionalidad y no por tipo, eso no significa que el tipo no sea importante ni que no lo diferenciemos de los demás. Por lo que además, podemos usar este artículo de índice para futuros artículos en los que expliquemos más en detalle uno a uno.
Sufijos
Durante los años que llevo desarrollando bajo feature oriented, hay una máxima que, aunque al principio era recomendable, finalmente se ha establecido como obligatoria: los sufijos.
Dado que no estamos englobando cada tipo de objeto en una carpeta con su nombre y namespace, el uso de sufijo que indique el tipo de objeto con el que estamos tratando es obligatorio.
Proyectos
Ante la aparición de nuevos frameworks compatibles con DotNet y C# (Xamarin, Xamarin.Forms, Uno Platform, Avalonia, etc…), cada día es más obligatorio la abstracción de la lógica en un proyecto a parte. Lo que antes era una simple recomendación si en un futuro veíamos una posible reutilización de código para otros proyectos, ahora es una obligación ante la posibilidad de cambiar de plataforma objetivo.
Este segundo proyecto de lógica no debe tener ninguna referencia al framework que estemos usando, y debemos evitar colocar código que no sea directamente relacionado con la plataforma. Una buena comprobación suele ser teorizar el traslado de la aplicación de móvil a escritorio o web y viceversa. Por ejemplo:
-¿Si esta aplicación móvil se llevase a escritorio usaría la misma navegación? -No, es probable que el diseño de algunas pantallas se amplíen o fragmenten, por lo que la navegación cambiaría.
En este caso, nuestro NavigationService
iría en el proyecto de plataforma. Si por el contrario nuestra respuesta fuese:
-Sí, tiene una navegación simple entre pantalla principal, ajustes y demás. En todas las plataformas será similar.
En tal caso, podríamos situar el NavigationService
en el proyecto de lógica.
Tipos de objetos
Vemos cuales son los tipos de archivos más comunes en cada proyecto, que nombre usamos y dónde irían situados. Para indicar un proyecto de plataforma o de lógica usaremos los términos App o Logic.
Esta tabla se irá actualizando con más futuros artículos con información sobre la responsabilidad de cada objeto.
Tipo de archivo | Sufijo/Nombre | Ubicación | Link |
---|---|---|---|
Base de las vistas | BaseContentPage BaseContentView … | [APP]/Bases/ | |
Base de los ViewModel | BaseViewModel BasePageViewModel … | [APP]/Bases/ | |
Controles | -Control -View -Cell … | [APP]/Controls/ [App]/Features/[Feature]/ | |
Páginas y vistas | -Page -View | [App]/Features/[Feature]/ | |
Code Behind Página | [App]/Features/[Feature]/ | ||
ViewModels | -ViewModel | [App]/Features/[Feature]/ | |
Feature Service | -Service | [App]/Features/[Feature]/ | |
App Service | -Service | [App]/Services/ | |
Logic Service | -Service | [Logic]/Services/ | |
Traducciones | Text.resx Text.[Idioma].resx | [App]/Features/[Feature]/ [App]/Resources/Localization/ | |
Feature Model | -Model | [App]/Features/[Feature]/ | |
Platform Model | -Model | [App]/Models/ | |
App Model | -Model | [Logic]/Models/ | |
Responses | -Response | [Logic]/Models/Responses [Logic]/Services/Api/Responses | |
Requests | -Request | [Logic]/Models/Requests [Logic]/Services/Api/Requests |
Hay más tipos de objetos que pueden ser necesarios para alguna aplicación, pero estos son los principales que necesitarás casi seguro en cualquier aplicación. Poco a poco iremos entrando en el detalle de algunos de ellos, ¡así que no dejes de volver a este artículo para ver la tabla con los nuevos enlaces actualizada!
¿Y tú? ¿Cómo gestionas tus archivos en tus proyectos?