¿Es un "olor de patrón" colocar a los usuarios como "FullName" o "FormattedPhoneNumber" en su modelo?

13

Estoy trabajando en una aplicación ASP.NET MVC, y me he acostumbrado a poner lo que parecen ser ú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 acerca de FullName y FormattedPhoneNumber getters.

Hacen que sea muy fácil crear formatos de datos estandarizados en toda la aplicación, y parecen guardar muchos códigos repetidos, pero definitivamente se podría argumentar que el formato de datos es algo que debe manejarse en el mapeo del modelo a la vista. modelo.

De hecho, originalmente estaba aplicando estos formatos de datos en mi capa de servicio donde realizo mi asignación, pero se estaba convirtiendo en una carga para tener que escribir constantemente formateadores y luego aplicarlos en muchos lugares diferentes. Por ejemplo, uso "Nombre completo" en la mayoría de las vistas, y tener que escribir algo como model.FullName = MappingUtilities.GetFullName(entity.FirstName, entity.LastName); por todas partes parece mucho menos elegante que solo escribir model.FullName = entity.FullName (o, si usa algo como AutoMapper, posiblemente no escriba nada en absoluto).

Entonces, ¿dónde traza la línea cuando se trata del formato de datos? ¿Está "bien" hacer el formateo de datos en su modelo o es un "olor de patrón"?

Nota: Definitivamente no tengo ningún html en mi modelo. Yo uso ayudantes html para eso. Estoy hablando estrictamente sobre el formato o la combinación de datos (y especialmente los datos que se usan con frecuencia).

    
pregunta devuxer 23.06.2011 - 23:31

4 respuestas

9

En su ejemplo, me gusta el FullName getter (por todas las razones que ha dado) pero no me gusta el formattedPhoneNumber getter. La razón es: probablemente no sea tan fácil (una vez que tenga números de teléfono internacionales, etc.) y si coloca la lógica para formar números de teléfono en un método de Member , es probable que necesite refactorizar (o copiar y pegar em> caugh ) una vez que necesite un número de teléfono con formato para Institution , Vendor etc. también.

EDITAR: IMO sería mejor tener una clase PhoneNumber con un Formatted getter.

    
respondido por el user281377 23.06.2011 - 23:47
5

Las cosas que debe tener en cuenta al escribir el código: ¿es correcto? ¿Es legible? ¿Es eficiente? ¿Es mantenible? Yo diría, como mencionó @btilly, 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 dispositivos de acceso como estos hace que su código sea más legible y, dependiendo de cómo lo use, podría 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 accesores de formato 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, usar un patrón no hace que su código tenga "olor de patrón" automáticamente. Necesitas abusar de él si quieres ganar ese atributo.

    
respondido por el Greg Jackson 23.06.2011 - 23:52
3

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

    
respondido por el Crazy Eddie 24.06.2011 - 01:01
1

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

Cuando esa decisión comience a fallar es cuando tiene los mismos datos que van a diferentes lugares que requieren formatos diferentes .

Si eso ocurriera, me sentiría tentado de volver a colocar la clase Member en:

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 hacer diferentes adaptadores para cada objetivo. Por ejemplo, supongamos que la información era necesaria en formato CSV:

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

Siempre asumiendo que ha saneado 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 ficticio parece encajar.

    
respondido por el Peter K. 23.06.2011 - 23:52

Lea otras preguntas en las etiquetas