¿Es un "olor a patrón" poner captadores como "FullName" o "FormattedPhoneNumber" en su modelo?

Estoy trabajando en una aplicación ASP.NET MVC, y me he acostumbrado a poner lo que parecen útiles y convenientes captadores en mis clases de modelo / entidad.

Por ejemplo:

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); }
    }
}

Me pregunto si la gente piensa en los FullNamey los FormattedPhoneNumbercaptadores.

Facilitan la creación de formatos de datos estandarizados en toda la aplicación, y parecen guardar una gran cantidad de código repetido, pero definitivamente se podría argumentar que el formato de datos es algo que debe manejarse en el mapeo de modelo a modelo de vista.

De hecho, originalmente estaba aplicando estos formatos de datos en mi capa de servicio donde hago mi mapeo, pero se estaba volviendo una carga tener que escribir constantemente formateadores y luego aplicarlos en muchos lugares diferentes. Por ejemplo, utilizo "Nombre completo" en la mayoría de las vistas, y tener que escribir algo parecido en model.FullName = MappingUtilities.GetFullName(entity.FirstName, entity.LastName);todo el lugar parece mucho menos elegante que simplemente escribir model.FullName = entity.FullName(o, si usa algo como AutoMapper, potencialmente no escribir nada).

Entonces, ¿dónde trazas la línea cuando se trata de formatear datos? ¿Está "bien" formatear los datos en su modelo o es un "olor a patrón"?

Nota: Definitivamente no tengo ningún html en mi modelo. Yo uso html helpers para eso. Estoy hablando estrictamente de formatear o combinar datos (y especialmente datos que se usan con frecuencia).

En su ejemplo, me gusta el FullNamegetter (por todas las razones que ha dado) pero no me gusta el getter FormattedPhoneNumber. La razón es: probablemente no es tan fácil (una vez que tenga los números internacionales de teléfono, etc.) y si se coloca la lógica para formatear números de teléfono en un método de Member, lo más probable es que tendrá que refactor (o copiar y pegar caugh ) una vez que se también necesita un número de teléfono con formato Institution, Vendoretc.

EDITAR: OMI sería mejor tener una PhoneNumberclase con un Formattedgetter.

Las cosas que debe tener en cuenta al escribir código: ¿es correcto? ¿Es legible? ¿Es eficiente? ¿Es mantenible? Yo diría, como @btilly mencionó, que no se puede mantener debido al formato específico de la cultura, pero la pregunta parece ser más general que eso.

El uso de accesores como estos hace que su código sea más legible y, dependiendo de cómo lo use, puede hacer que otras partes de su código sean mucho más limpias. En mi opinión, eso no huele en absoluto. Comenzaría a oler si tuviera formateadores para cualquier tipo de cadena que desee imprimir ( public string FirstLastName; public string FullName; public string FullNameWithMiddleInitial; public string PhoneNumberWithAreaCode; public string PhoneNumberWithoutAreaCode; public string PhoneNumberWithCountryCode;, etc.)

O, para decirlo de otra manera, el uso de un patrón no hace que su código tenga automáticamente "olor a patrón". Necesitas abusar de él si quieres ganar ese atributo.

Rompe el principio de responsabilidad única. ¿Por qué no hacer una clase de número de teléfono, etc.?

Para su ejemplo, no lo veo como un gran problema para usar formatos específicos. Es una o dos y todas las partes de la aplicación usan el mismo formato.

Donde esa decisión comenzaría a romperse es cuando tienes los mismos datos yendo a varios lugares diferentes que requieren diferentes formatos .

Si eso sucediera, me vería tentado a Memberdevolver la clase a:

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

Y luego haga diferentes adaptadores para cada objetivo. Por ejemplo, suponga que la información se requiere en formato CSV:

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

Siempre suponiendo que haya desinfectado los datos para que no haya comas, etc., en las cadenas.

El adaptador no tiene que ser un método de extensión, pero para este caso imaginario parece encajar.