Migration .Net 8 et surprises

Version imprimable

Bonjour,

Je suis actuellement en train de migrer des API REST de .Net 7 vers .Net 8, et j'en profite pour revoir un petit peu le code.
J'ai le code suivant qui fonctionne très bien mais qui génère un message me conseillant d'utiliser un constructeur primaire (IDE0290).

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
/// <summary>
/// Service de consultation des données de Popo
/// </summary>
[ApiVersion("2.0")]
public class PopoConsultationController : BaseController
{
    #region constructor
    public PopoConsultationController(IPopoConsultationService popoConsultationService
       ) : base()
    {
        _popoConsultationService = popoConsultationService;
    }
    #endregion constructor
 
    #region Actions
    /// <summary>
    /// ViewPopo
    /// </summary>
    /// <remarks>
    /// Cette méthode restitue les informations sur POPO.
    /// </remarks>
    /// <verb>Get</verb>
    /// <url>https://entreprise.com/PopoConsultationWebService/ViewPopo</url>
    /// <response code="200"><see cref="ViewPopoOutDto"/>
    /// Informations relatives à Popo.
    /// </response>
    [HttpGet]
    [ProducesResponseType(typeof(ViewPopoOutDto), StatusCodes.Status200OK)]
    [ProducesResponseType(StatusCodes.Status404NotFound)]
    [MapToApiVersion("2.0")]
    public async Task<IActionResult> ViewPopo)
    {
        return await InvokeAsync(_popoConsultationService.ViewPopoAsync);
    }
    #endregion Actions
 
    #region Private
    private readonly IPopoConsultationService _popoConsultationService;
    #endregion Private
}

Dans le XML de documentation cela me génère, entre autre le membre suivant, ce qui est tout à fait normal :

Code:

1
2
3
4
5
<member name="T:Entreprise.Controllers.V2.PopoConsultationController">
            <summary>
            Service de consultation des données de Popo.
            </summary>
        </member>

Visual Studio me suggère de transformer mon code en ceci :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
 /// <summary>
 /// Service de consultation des données de Popo.
 /// </summary>
 [ApiVersion("2.0")]
public class PopoConsultationController(IPopoConsultationService PopoConsultationService
       ) : BaseController()
{
 
    #region constructor
    #endregion constructor
 
    #region Actions
    /// <summary>
    /// ViewPopo
    /// </summary>
    /// <remarks>
    /// Cette méthode restitue les informations sur POPO.
    /// </remarks>
    /// <verb>Get</verb>
    /// <url>https://entreprise.com/PopoConsultationWebService/ViewPopo</url>
    /// <response code="200"><see cref="ViewPopoOutDto"/>
    /// Informations relatives à Popo.
    /// </response>
    [HttpGet]
    [ProducesResponseType(typeof(ViewPopoOutDto), StatusCodes.Status200OK)]
    [ProducesResponseType(StatusCodes.Status404NotFound)]
    [MapToApiVersion("2.0")]
    public async Task<IActionResult> ViewPopo()
    {
        return await InvokeAsync(_PopoConsultationService.ViewPopoAsync);
    }
    #endregion Actions
 
    #region Private
    private readonly IPopoConsultationService _PopoConsultationService = PopoConsultationService;
    #endregion Private
}

La suggestion IDE0290 disparait mais cela génère du contenu supplémentaire dans le XML de documentation.

Code:

1
2
3
4
5
6
7
8
9
10
<member name="T:Entreprise.Controllers.V2.PopoConsultationController">
            <summary>
            Service de consultation des données de Popo.
            </summary>
        </member>
        <member name="M:Entreprise.Controllers.V2.PopoConsultationController.#ctor(Entreprise.PopoSrv.IPopoConsultationService)">
            <summary>
            Service de consultation des données de Popo.
            </summary>
        </member>

Existe-t-il un moyen d'utiliser le constructeur primaire sans impacter le XML de documentation ?
Merci.

29/01/2025, 13h36
StringBuilder

Salut,

Aucune idée pour ta réponse, par contre, autant généralement je trouve vachement bonnes les simplifications syntaxiques apportées par les évolutions de .NET, autant pour le coup, le contructeur primaire je trouve ça ultra merdique, sauf pour des classes ultra basiques dénuées et méthodes et interrigence (et encore... franchement).

Je trouve que ça nuit très grandement à la lisibilité, et tu dois faire machine arrière dès que tu introduis un constructeur alternatif.

Et si en plus ça boudille la documentation automatique...

Bref, poubelle.

Ce sont des contrôleurs, donc le code n'a rien de compliqué.
C'est justement un code que je qualifierai de basique puisqu'il cette couche REST se contente d'appeler la couche APPLICATION.

D'ailleurs, ce code peut encore être simplifié de cette manière puisque je peux me servir directement de ce qui est passé dans le constructeur primaire sans avoir besoin de le stocker.
Moi, je trouve ça extrêmement simple, au contraire.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 /// <summary> /// Service de consultation des données de Popo. /// </summary> [ApiVersion("2.0")] public class PopoConsultationController(IPopoConsultationService PopoConsultationService ) : BaseController() { #region Actions /// <summary> /// ViewPopo /// </summary> /// <remarks> /// Cette méthode restitue les informations sur POPO. /// </remarks> /// <verb>Get</verb> /// <url>https://entreprise.com/PopoConsultationWebService/ViewPopo</url> /// <response code="200"><see cref="ViewPopoOutDto"/> /// Informations relatives à Popo. /// </response> [HttpGet] [ProducesResponseType(typeof(ViewPopoOutDto), StatusCodes.Status200OK)] [ProducesResponseType(StatusCodes.Status404NotFound)] [MapToApiVersion("2.0")] public async Task<IActionResult> ViewPopo() { return await InvokeAsync(PopoConsultationService.ViewPopoAsync); } #endregion Actions }
Je ne comprend pas ta remarque sur le constructeur alternatif.
Pour moi, il n' y a pas besoin de faire machine arrière, simplement de déclaration un second constructeur qui appelle le primaire avec this.
Comme ceci (trouvé sur cette page) :
Code:

1 2 3 4 5 6 7 public class Student(int id, string name, IEnumerable<decimal> grades) { public Student(int id, string name) : this(id, name, Enumerable.Empty<decimal>()) { } public int Id => id; public string Name { get; set; } = name.Trim(); public decimal GPA => grades.Any() ? grades.Average() : 4.0m; }
Edit :
Après vérification, cela n'a pas d'incidence sur la page APIM vue par le client.
Dans la mesure où cela n'a pas d'impact, ce n'est pas vraiment un problème.
Je passe donc en résolu.

30/01/2025, 16h21
StringBuilder

Citation:

Envoyé par popo

Je ne comprend pas ta remarque sur le constructeur alternatif.
Pour moi, il n' y a pas besoin de faire machine arrière, simplement de déclaration un second constructeur qui appelle le primaire avec this.

Hmmm, soit j'ai rêvé, soir j'étais dans un cas à la noix (si on passe pas par : this(x, y, z) il se passe quoi ?

Dans tout les cas, je trouve que le code devient franchement illisible.

Autant user et abuser de : this(x, y, z), oui à 100%, autant avoir la signature d'un constructeur planqué au niveau de la déclaration du nom de la classe, et des variable qui sortent du chapeau au nieau de l'initialisation des attributs... Honnêtement ça me donne les yeux rouges et une rupture d'anévrisme.
30/01/2025, 18h07
popo

Citation:

Envoyé par StringBuilder

Hmmm, soit j'ai rêvé, soir j'étais dans un cas à la noix (si on passe pas par : this(x, y, z) il se passe quoi ?

Avec un constructeur primaire, si tu passes pas : this(x, y, z) sur le second constructeur, tu ne compileras pas.
Il n'y a aucune chance de l'oublier.

Avec un constructeur classique, tu dois également appeler : this(x, y, z).
Sinon, tu devras dupliquer l'affectation de l'identifiant et du nom.
Et si tu oublies de faire l'un ou l'autre, tu auras potentiellement un bug lié au faut que des valeurs par défaut seront mise dans l'identifiant et le nom.

Citation:

Envoyé par StringBuilder

Dans tout les cas, je trouve que le code devient franchement illisible.

Autant user et abuser de : this(x, y, z), oui à 100%, autant avoir la signature d'un constructeur planqué au niveau de la déclaration du nom de la classe, et des variable qui sortent du chapeau au nieau de l'initialisation des attributs... Honnêtement ça me donne les yeux rouges et une rupture d'anévrisme.

C'est un point de vue.
Moi j'ai l'habitude de placer les constructeurs au début de classe.
Donc le constructeur primaire apparait juste avant les secondaires.
Ce n'est pas ce que j'appelle planqué.

Des variables qui sortent du chapeau ?
Ces variables seront également demandées avec un constructeur classique.
Dans le reste de la classe, on utilisera id de la même façon.
La seule différence, c'est que je n'ai plus besoin de déclarer un membre privé et d'y transférer la valeur avec this.id = id.