Editar

Compartir a través de

Nomenclatura de proyectos y espacios de nombres de Gridwich

Azure Functions

Gridwich es una solución de .NET 6 formada por varios proyectos. Es importante que los proyectos de código tengan una convención de nomenclatura para ayudar a entender la estructura de la aplicación, encontrar código pertinente rápidamente y reducir el efecto del estacionamiento de bicicletas en la nomenclatura de proyectos.

El sistema Gridwich tiene tres componentes principales, Core, Host.FunctionApp y SagaParticipants.

  • El proyecto Core tiene interfaces para todo el sistema, modelos, objetos de transferencia de datos (DTO) y clases base.

    Los proyectos Core.{Technology} tienen las clases de cliente y las funcionalidades base que usan varias implementaciones de funcionalidades.

  • El proyecto Host.FunctionApp es la interfaz pública para el sistema global.

  • Los proyectos SagaParticipants proporcionan funcionalidades externas, como el análisis, la codificación, la publicación y el almacenamiento.

    Los proyectos SagaParticipants.{Capability} describen las interfaces, las excepciones y los eventos que produce una funcionalidad.

    Los proyectos SagaParticipants.{Capability}.{Technology} proporcionan una implementación de funcionalidades real, clientes de escucha de eventos y funcionalidades específicas.

Un proyecto Technology de Gridwich es una implementación real de una funcionalidad o función principal. Un proyecto {Technology} puede encontrarse bajo un espacio de nombres Core o SagaParticipants.{Capability} y un nombre de proyecto, dependiendo del uso.

Creación de un proyecto

Puede usar el siguiente árbol de decisión al nombrar un nuevo proyecto de Gridwich:

¿El código es un contrato, como clases base, interfaces, modelos u objetos de transferencia de datos, o una extensión de servicio?

  • Sí: ¿El código está relacionado con una capacidad o servicio específicos?

    • Sí: Gridwich.SagaParticipants.{Capability}
    • No: Gridwich.Core

  • No: ¿El código está relacionado con un cliente de escucha de eventos o con una implementación de una tecnología específica?

    • Sí: ¿Usará más de un servicio el código?

      • Sí, por ejemplo, un contenedor de SDK: Gridwich.Core.{Technology}
      • No: Gridwich.SagaParticipants.{Capability}.{Technology}

    • No: ¿El código está relacionado con una funcionalidad específica?

      • Sí: Gridwich.SagaParticipants.{Capability}

      • No: ¿El código es un punto de conexión de Azure Function App?

        • Sí: Gridwich.Host.FunctionApp
        • No: Gridwich.Core

Estructura del proyecto

Cada paquete tiene dos subdirectorios secundarios:

  • src contiene el código de producción que no es de prueba.
  • tests contiene pruebas unitarias.

Cada proyecto tiene un subdirectorio tests, pero si no hay pruebas unitarias para un paquete, el directorio puede estar vacío.

Cada uno de los dos subdirectorios contiene los archivos C# o de otro tipo para compilar el código, más un archivo .csproj. El nombre del archivo .csproj sigue el nombre del paquete, por ejemplo:

  • Gridwich.Host.FunctionApp/src/Gridwich.Host.FunctionApp.csproj
  • Gridwich.Host.FunctionApp/tests/Gridwich.Host.FunctionAppTests.csproj

Los espacios de nombres de código que los paquetes usan también siguen esta convención, por ejemplo:

  • Gridwich.Host.FunctionApp
  • Gridwich.Host.FunctionAppTests

Durante los ciclos de compilación y prueba, aparecen directorios transitorios como bin, objy TestResults, que contienen artefactos no aptos para Git. El procesamiento dotnet clean limpia estos directorios transitorios.

Nombres de proyecto y espacios de nombres

Los nombres de proyecto y los espacios de nombres de Gridwich tienen las siguientes características.

Espacios de nombres de tecnología Core y SagaParticipants

Los espacios de nombres Gridwich.Core.{Technology} no incluyen el propósito de la tecnología, principalmente evitar el efecto del estacionamiento de bicicletas. Los espacios de nombres Core son proyectos internos que los proyectos SagaParticipants o Host.FunctionApp usan, y no necesitan nombres bien definidos.

Por ejemplo, el Gridwich.Core.EventGrid proyecto podría ser Gridwich.Core.Events.EventGrid o Gridwich.Core.Messaging.EventGrid. Sin embargo, los nombres de proyecto de Core ya sugieren que las tecnologías contribuyen al sistema principal.

Una tecnología también podría contribuir al sistema de varias maneras. Por ejemplo, podría considerar a Redis un almacén de datos o servicio de transporte de mensajería, en función de su uso, pero siempre usará el mismo contenedor de SDK.

Los espacios de nombres de tecnología Gridwich.SagaParticipants.Encode.CloudPort y Gridwich.SagaParticipants.Encode.Flip usan componentes del espacio de nombres Gridwich.SagaParticipants.Encode. Este código no está en el espacio de nombres Gridwich.Core.Encode porque es específico de las tareas de codificación y no se cruza con otras funcionalidades, como la publicación.

Paquetes de SagaParticipants

No todos los paquetes de Gridwich.SagaParticipants procesan eventos externos. Algunos paquetes de Gridwich.SagaParticipants proporcionan funcionalidad para otros participantes de saga que procesan solicitudes externas.

Además del paquete de Gridwich.SagaParticipants.Encode que comparte código entre varios paquetes de tecnología de codificación, también hay paquetes especializados como Gridwich.SagaParticipants.Encode.TelestreamCloud. El paquete Telestream proporciona acceso de Gridwich a un sistema Vantage Telestream externo. Los participantes de saga Flip y CloudPort usan el paquete Telestream para proporcionar su propio procesamiento de solicitudes.

Nombres de paquete y otros espacios de nombres

Para mantener las instrucciones using al mínimo, Gridwich no restringe el contenido del paquete al espacio de nombres que indica el nombre del paquete. Algunos paquetes aportan entidades a otros espacios de nombres. Por ejemplo, el paquete Gridwich.Core.Tests aporta la clase Gridwich.Core.Helpers.TestHelpers.

Sin embargo, cada paquete genera un archivo DLL que coincide con el nombre del paquete para el código de producción en src, y un archivo DLL de pruebas unitarias, si las hay, en tests. El nombre del archivo DLL de prueba es el mismo que el nombre del paquete, pero con un sufijo Tests.

Pasos siguientes

Documentación del producto:

Módulos de Microsoft Learn: