¿Hay algún daño en tener muchos valores enum? (muchos> = 1000)

Tengo una larga lista de mensajes de error que mi código de negocio puede devolver en función de lo que se ingresó. La lista puede terminar con más de mil.¿Hay algún daño en tener muchos valores enum? (muchos> = 1000)

Me gustaría enumerar todo esto, utilizando el atributo [Descripción ("")] para registrar el mensaje amistoso.

Algo así como:

public enum ErrorMessage 
{ 
    [Description("A first name is required for users.")] 
    User_FirstName_Required = 1, 
    [Description("The first name is too long. It cannot exceed 32 characters.")] 
    User_FirstName_Length = 2, 
    ... 
}

sé enumeraciones son tipos primitivos, específicamente enteros. No debería haber ningún problema con tantos enteros, ¿verdad?

¿Hay algo en lo que no estoy pensando? Parece que esto debería estar bien, pero pensé que debería preguntarle a la comunidad antes de pasar el tiempo para hacerlo de esta manera.

¿A .Net le importan los tipos enum de forma diferente cuando tienen muchos valores?

actualización

La razón por la que no quería utilizar los recursos se debe a

a) tengo que ser capaz de hacer referencia a cada mensaje de error único con un valor entero. La capa biz sirve a una API, además de otras cosas, y se debe devolver una lista de valores enteros que denotan los errores. No creo que los recursos le permitan abordar un valor de recurso con un número entero. ¿Me equivoco?

b) No hay requisitos de localización.

Fuente

2010-10-31 sohtimsso1970

Los metadatos de conjunto suelen estar limitados a 65535 elementos distintos por agrupamiento. –

1000 no es muchos, sólo debe asegurarse de que el tipo entero subyacente es lo suficientemente grande (no utilice un char para su enum.

En el segundo pensamiento 1.000 toneladas es si usted está entrando manualmente , si se generan a partir de algún conjunto de datos podría tener sentido un poco ...

Fuente

2010-10-31 18:53:26 Motti

Creo que un diseño que tiene más de 1000 valores en una enumeración necesita más reflexión. Parece que un antipatrón "God Enum" tendrá para ser inventado para este caso.

Fuente

2010-10-31 18:53:35 duffymo

Pensé en usar tipos genéricos de ErrorMessage contra el modelo, pero parece que el único punto de eso sería tener menos código vertical y más código horizontal. Mi plan es iterar a algo mejor a medida que los requisitos futuros se vuelvan más claros. – sohtimsso1970

Mientras que en un caso general, diría que es un signo de mal diseño, creo que tiene sobre el único caso de fiar, un código de resultado que se debe pasar como un entero. –

El principal inconveniente que señalaría con el amistoso de La inscripción en un atributo es que esto causará problemas si alguna vez necesita localizar su aplicación para otro idioma. Si esto es una consideración, sería una buena idea poner las cadenas en un archivo de recursos.

La enumeración en sí no debería ser un problema, aunque tener todos los códigos de error en una lista maestra puede ser confuso. Puede considerar la creación de enumeraciones separadas para categorías separadas de códigos de retorno, ya que esto facilitará que los desarrolladores entiendan los posibles valores de retorno para una función en particular. Aún puede darles valores numéricos distintos (especificando explícitamente los valores numéricos) si es importante que los códigos sean únicos.

En una nota lateral, .NET BCL no hace mucho uso de los códigos de retorno y los códigos de retorno son algo desalentados en el desarrollo moderno de .NET. Crean problemas de mantenimiento (casi nunca se pueden eliminar los códigos de retorno antiguos o se corre el riesgo de romper la compatibilidad con versiones anteriores) y requieren una lógica de validación especial para manejar las devoluciones de cada llamada. La validación con estado se puede lograr con IDataErrorInfo, donde se usa una clase intermedia que puede representar estados inválidos, pero que solo permite un Compromiso de cambios que se validan. Esto le permite manipular el objeto libremente, pero también proporcionar retroalimentación al usuario sobre la validez de su estado.La lógica equivalente con códigos de error a menudo requiere una instrucción switch para cada uso.

Fuente

2010-10-31 18:54:40

Sí, pensé en la localización, pero eso no es necesario, y es muy poco probable que lo sea. Me imagino que si ese requisito alguna vez sale a la superficie, haré que el equipo itere a otra cosa. – sohtimsso1970

Hace una buena observación sobre el uso de estado válido/inválido con una interfaz, pero no estoy de acuerdo con que se desaconsejen los tipos de devolución. Esta enumeración ErrorMessage no es lo único que se devuelve. Es parte de un patrón de resultado que permite que la capa de negocio devuelva una gran cantidad de información que no es posible de otra manera. (Al menos no que yo pueda comprender). Tenga en cuenta que esta capa de negocios está apareciendo en una variedad de tipos de controladores, que incluyen una API REST y SOAP. – sohtimsso1970

@sohtimsso1970, parece que su caso de uso es una excepción, ya que necesita empaquetar más información que solo un código de retorno. Me refería más al enfoque de la vieja escuela de hacer que cada llamada al método devolviera un número entero, con un conjunto principal de constantes para interpretar el resultado de cada método. En su caso, necesita admitir múltiples frentes de servicio, por lo que un código de error para comunicar la validación puede tener el mejor sentido. Aún así, será útil dividir los códigos/resultados; Creo que tener un 'Resultado 'central va a causar dolores de cabeza más tarde. –

Estoy completamente de acuerdo con duffymo. Una enumeración con más de 1000 valores huele mal desde el punto de vista del diseño. Sin mencionar que sería bastante desagradable para el desarrollador usar la inteligencia en un GOD ENUM :-) Será mejor que vaya por el uso de los recursos.

Fuente

2010-10-31 18:57:56

La razón por la que no quiero ir con los recursos es porque necesito devolver un valor entero único para cada error. El código de biz se está utilizando en diferentes lugares, incluida una API, por lo que hay momentos en que no puedo pasar el Nombre del recurso, pero tendría que pasar un int. Editaré la pregunta para incluir esto. – sohtimsso1970

Por cierto, ¿lees la [Descripción ("Se requiere un nombre para los usuarios.")] En tiempo de ejecución? Eso podría afectar el rendimiento. –

Sí, hay un punto donde se usa la reflexión para obtener la Descripción, pero eso solo ocurre una vez por instancia de aplicación, ¿no? Tan pronto como se tome ese golpe, no debería volver a suceder a menos que la aplicación se reinicie. – sohtimsso1970

Creo que es muy malo, para el manejo de errores simplemente puede utilizar el recurso, ya que veo que quiere hacer una reflexión y buscar la descripción es malo también. Si no desea utilizar los recursos, puede definir enum diferente para cada una de las reglas de su negocio, también su negocio diferente no necesita otros mensaje de error (y no debería ser así).

Fuente

2010-10-31 18:59:47

¿Quién dejó un voto negativo? por favor explica por qué? –

¿Hay algún daño en tener muchos valores enum? (muchos> = 1000)

Respuesta

Cuestiones relacionadas