Est-ce une «odeur de motif» de mettre des getters comme «FullName» ou «FormattedPhoneNumber» dans votre modèle?

Je travaille sur une application ASP.NET MVC, et j'ai pris l'habitude de mettre ce qui semble être des getters utiles et pratiques dans mes classes de modèle / entité.

Par exemple:

public class Member
{
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string PhoneNumber { get; set; }

    public string FullName
    {
        get { return FirstName + " " + LastName; }
    }

    public string FormattedPhoneNumber
    {
        get { return "(" + PhoneNumber.Substring(0, 3) + ") " + PhoneNumber.Substring(3, 3) + "-" + PhoneNumber.Substring(6); }
    }
}

Je me demande si les gens pensent aux FullNameet aux FormattedPhoneNumbergetters.

Ils facilitent la création de formats de données standardisés dans l'application et semblent économiser beaucoup de code répété, mais on pourrait certainement affirmer que le format de données est quelque chose qui devrait être géré lors du mappage d'un modèle à un modèle de vue.

En fait, à l'origine, j'appliquais ces formats de données dans ma couche de service où je fais mon mappage, mais cela devenait un fardeau d'avoir constamment à écrire des formateurs, puis à les appliquer à de nombreux endroits différents. Par exemple, j'utilise "Nom complet" dans la plupart des vues, et avoir à taper quelque chose comme model.FullName = MappingUtilities.GetFullName(entity.FirstName, entity.LastName);partout semblait beaucoup moins élégant que de simplement taper model.FullName = entity.FullName(ou, si vous utilisez quelque chose comme AutoMapper, potentiellement ne rien taper du tout).

Alors, où tracez-vous la ligne en ce qui concerne le formatage des données. Est-il «correct» de mettre en forme les données dans votre modèle ou est-ce une «odeur de motif»?

Remarque: je n'ai certainement pas de code HTML dans mon modèle. J'utilise des aides html pour cela. Je parle strictement de formatage ou de combinaison de données (et en particulier de données fréquemment utilisées).

Dans votre exemple, j'aime le FullNamegetter (pour toutes les raisons que vous avez données) mais je n'aime pas le getter FormattedPhoneNumber. La raison en est: ce n'est probablement pas si facile (une fois que vous avez des numéros de téléphone internationaux, etc.) et si vous placez la logique de formatage des numéros de téléphone dans une méthode de Member, vous aurez probablement besoin de refactoriser (ou copier-coller caugh ) une fois que vous besoin d'un numéro de téléphone formaté pour Institution, Vendoretc. aussi.

EDIT: OMI, il serait préférable d'avoir une PhoneNumberclasse avec un Formattedgetter.

Les choses que vous devez considérer lors de l'écriture de code: est-ce correct? Est-il lisible? Est-ce efficace? Est-il maintenable? Je dirais, comme @btilly l'a mentionné, que ce n'est pas maintenable en raison du formatage spécifique à la culture, mais la question semble être plus générale que cela.

L'utilisation d'accesseurs comme ceux-ci rend votre code plus lisible et, selon la façon dont vous l'utilisez, peut rendre les autres parties de votre code beaucoup plus propres. À mon avis, cela ne sent pas du tout. Cela commencerait à sentir si vous aviez des accesseurs de formatage pour tout type de chaîne que vous pourriez vouloir imprimer ( public string FirstLastName; public string FullName; public string FullNameWithMiddleInitial; public string PhoneNumberWithAreaCode; public string PhoneNumberWithoutAreaCode; public string PhoneNumberWithCountryCode;, etc.)

Ou, pour le dire autrement, l'utilisation d'un motif ne fait pas automatiquement que votre code ait une "odeur de motif". Vous devez en abuser si vous voulez gagner cet attribut.

Brise le principe de la responsabilité unique. Pourquoi ne pas faire une classe de numéro de téléphone, etc ...?

Pour votre exemple, je ne pense pas que ce soit trop important pour utiliser des formats spécifiques. C'est une ou deux et toutes les parties de l'application utilisent le même format.

Lorsque cette décision commencerait à s'effondrer, c'est lorsque vous avez les mêmes données à plusieurs endroits différents nécessitant des formats différents .

Si cela arrivait, je serais tenté de Memberramener la classe à:

public class Member
{
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string PhoneNumber { get; set; }  
}

Et puis faites des adaptateurs différents pour chaque cible. Par exemple, supposons que les informations étaient requises au format CSV:

public static class CSVMemberAdapter
{
    public static string ToCSV(this Member mbr)
    {
         return mbr.Id + "," + mbr.LastName + "," + mbr.FirstName, "," mbr.PhoneNumber;
    }
}

En supposant toujours que vous avez nettoyé les données afin qu'aucune virgule, etc. ne soit dans les chaînes.

L'adaptateur ne doit pas être une méthode d'extension, mais pour ce cas imaginaire, il semble convenir.