É um “cheiro de padrão” colocar getters como “FullName” ou “FormattedPhoneNumber” no seu modelo?

Estou trabalhando em um aplicativo ASP.NET MVC e tenho adquirido o hábito de colocar o que parecem ser úteis e convenientes getters em minhas classes de modelo / entidade.

Por exemplo:

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

Eu estou querendo saber as pessoas pensam sobre o FullNamee FormattedPhoneNumbergetters.

Eles facilitam a criação de formatos de dados padronizados em todo o aplicativo e parecem economizar muito código repetido, mas definitivamente pode-se argumentar que o formato dos dados é algo que deve ser tratado no mapeamento de modelo para modelo de exibição.

De fato, originalmente eu estava aplicando esses formatos de dados na camada de serviço em que faço o mapeamento, mas estava se tornando um fardo precisar constantemente escrever formatadores e aplicá-los em muitos lugares diferentes. Por exemplo, eu uso "Nome completo" na maioria das visualizações e ter que digitar algo como em model.FullName = MappingUtilities.GetFullName(entity.FirstName, entity.LastName);todo o lugar parecia muito menos elegante do que apenas digitar model.FullName = entity.FullName(ou, se você usar algo como o AutoMapper, provavelmente não digita nada).

Então, onde você desenha a linha quando se trata de formatação de dados. É "bom" fazer a formatação de dados no seu modelo ou é um "cheiro de padrão"?

Nota: eu definitivamente não tenho nenhum html no meu modelo. Eu uso ajudantes html para isso. Estou falando estritamente sobre formatação ou combinação de dados (e especialmente dados usados ​​com freqüência).

No seu exemplo, eu gosto do FullNamegetter (por todos os motivos que você deu), mas não gosto do getter FormattedPhoneNumber. A razão é: provavelmente não é assim tão fácil (uma vez que você tem números internacionais de telefone etc.) e se você colocar a lógica de formatação números de telefone em um método de Member, as chances são que você vai precisar para refatorar (ou copiar e colar caugh ) uma vez que você também precisa de um número de telefone formatado Institution, Vendoretc.

EDIT: IMO, seria melhor ter uma PhoneNumberclasse com um Formattedgetter.

O que você precisa considerar ao escrever um código: está correto? É legível? É eficiente? É sustentável? Eu argumentaria, como @btilly mencionou, que não é sustentável devido à formatação específica da cultura, mas a questão parece ser mais geral do que isso.

Usar acessadores como esses torna seu código mais legível e, dependendo de como você o usa, pode tornar outras partes do código muito mais limpas. Na minha opinião, isso não cheira nada. Começaria a cheirar se você tivesse acessadores de formatação para qualquer tipo de string que você queira imprimir ( public string FirstLastName; public string FullName; public string FullNameWithMiddleInitial; public string PhoneNumberWithAreaCode; public string PhoneNumberWithoutAreaCode; public string PhoneNumberWithCountryCode;, etc)

Ou, em outras palavras, o uso de um padrão não faz com que seu código tenha "cheiro de padrão" automaticamente. Você precisa abusar dele se quiser ganhar esse atributo.

Quebra o princípio da responsabilidade única. Por que não fazer uma classe de número de telefone, etc ...?

Para o seu exemplo, não considero muito difícil usar formatos específicos. É uma ou duas e todas as partes do aplicativo usam o mesmo formato.

O ponto em que essa decisão começaria a ser interrompida é quando você tem os mesmos dados em vários locais diferentes, exigindo formatos diferentes .

Se isso acontecesse, eu ficaria tentado a puxar a Memberturma de volta para:

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

E, em seguida, faça adaptadores diferentes para cada destino. Por exemplo, suponha que as informações sejam necessárias no formato CSV:

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

Sempre assumindo que você limpou os dados para que não haja vírgulas etc. nas strings.

O adaptador não precisa ser um método de extensão, mas, para esse caso de simulação, parece se encaixar.