ayudaría más si puede proporcionar más información, por ejemplo, cómo se ve su modelo actual. con la información actual, veo el siguiente enfoque que puede ayudarlo

asumiendo que este es su modelo de factura

 public class invoice { public int Id { get; set; } DatabaseGenerated(DatabaseGeneratedOption.Computed)] public string InvoiceNumber { get; set; } //other properties }

luego, en su generador de modelos, haga lo siguiente

 protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.Entity<invoice>() .Property(b => b.Created) .HasComputedColumnSql("[somepropertyoftable] + ', ' + getdate()"); }

El siguiente enlace puede ser útil:

https://docs.microsoft.com/en-us/ef/core/modeling/generated-properties?tabs=data-annotations

Intentaré responder esto también; Parece que tiene dos inquietudes aquí, que podrían ser la misma inquietud, dicho de otra manera, es posible que no esté entendiendo su pregunta.

1. Generación de un número de serie único
2. Incremento del número de factura.

Aquí hay algunas opciones potenciales...

Aproveche SQL para sus números de incremento automático...

• Un buen estilo arquitectónico retrasa decisiones; ¿Quieres confiar en el servidor sql para generarlos por ti? Si está de acuerdo con nunca usar una base de datos diferente, entonces, dejar que sql genere un número de incremento automático para usted debería estar bien.
• Sin embargo, si alguna vez desea utilizar un almacén de datos diferente, sería cauteloso e implementaría el repositorio y eso puede contener la lógica para generar un número de serie único para su registro de factura. Por lo tanto, desacopla la generación del identificador único del almacén de datos.
• Sin embargo, no estoy seguro de que realmente logre por completo lo que está buscando. Parece que necesita caracteres y dígitos, entonces la pregunta sería, ¿en qué formato debe estar? ¿Hay restricciones? Por ejemplo, todas las facturas en México se adjuntan con MX- .

Implementar el repositorio

• La generación de seriales únicos y sus restricciones se puede hacer aquí; la prueba es fácil con un controlador> patrón de repositorio, normalmente uso Moq . Esto le permite alejar esta preocupación del controlador cuando en realidad todo lo que quiere hacer es aceptar una solicitud POST y llamar a _repository.AddInvoice(invoice); .
• Luego, el repositorio puede manejar el resto, según la lógica y los requisitos de su negocio.

Implementar la generación de este identificador en el objeto de dominio

• Martin Fowler tiene este artículo si está interesado en la difícil situación de los modelos de dominio anémicos. Básicamente, el TL;DR en él es encapsular los datos y el comportamiento de los mismos en el propio modelo. Esto (debería) facilitar las pruebas.