¿Está bien usar una clase como esta (diseño/guía específica)? Estoy usando el patrón MVVM.Public const string?
public static class Pages
{
public const string Home = "Home.xaml";
public const string View2 = "View2.xaml";
/* a few more... */
}
Existen diferencias significativas entre const y public static readonly, y usted debe considerar cuál utilizar con cuidado:
(Por "cliente" aquí, significa "código de una manera diferente Asamblea refiriéndose al miembro.)
const. con public static readonly, verán el valor actualizado. Si vuelve a compilar todos los clientes cualquier manera, esto no es un problema.const es un tiempo de compilación constante, lo que significa que se puede utilizar en:
Si' Estaremos encantados de recompilar a todos sus clientes si alguna vez cambia el valor, los beneficios del segundo punto de viñeta hacia el uso de const.
Por supuesto, me pregunto si realmente Pages necesidades sean públicas de todos modos ... suena como algo que podría ser internal, con internal miembros - momento en el que las desventajas de const desaparecen por completo.
Una pauta general cuando se utiliza const para definir valores constantes. ¿Se debe acceder a estas constantes fuera del ensamblaje? Si no, entonces la declara como
internal static class Pages
{
public const string Home = "Home.xaml";
public const string View2 = "View2.xaml";
/* a few more... */
}
Definitivamente vale la pena entender los pros y los contras antes de dar el consejo universal de "use static readonly en lugar de const". Considere el contexto en el que si el conjunto X cambia, todos los clientes se reconstruirán de todos modos, un contexto bastante común en los negocios. ¿Eso cambia el consejo que darías? –
@JonSkeet ¡No era algo que debías usar de forma inmediata! Ya hice una pregunta con una respuesta. Realmente no creo que en este caso la clase pública sea necesaria, así que sugerí usar la clase interna. Además, pensé que es útil saber cómo funciona const y readonly; por lo tanto, el enlace para el artículo. De todos modos, debería estar de acuerdo con lo que sugirió aquí. :-) – AksharRoop
Bueno, básicamente dijiste "Si debe ser público, usa público estático de solo lectura". Si alguien que lee este sitio no tiene C# eficaz, no obtendrá mucha información inmediata sobre los casos en los que en realidad ese es * * consejo aplicable, incluso si debe ser público. –
Desde el punto de vista del diseño de su pregunta, parece que podría deshacerse rápidamente utilizando un solo objeto estático para contener todas las referencias de página. ¿No puedes simplemente almacenarlo en el objeto de la página real?
class view2 {
public const string PageName = "View2.xaml";
... other stuff ...
}
entonces llaman a lo largo de las líneas de ...
goTo(view2.PageName);
Creo que esta es una de las mejores cosas que puede hacer. Algunas más sugerencias: con cuerdas está perfectamente bien usar const s. En caso de que desee usar tipos diferentes, use static readonly y luego inicialícelo en un constructor static.
Para una aproximación diferente usando enums, vea this thread. Como lo que estás tratando de hacer se parece mucho a una enumeración de cadenas, ese podría ser el camino a seguir para ti.
Y no olvide que siempre que especifique sus páginas en el código, realizar cambios (por ejemplo, cambiar el nombre o mover una página) será un problema. Considere usar algo como recursos o mapas de sitio. (En caso de que única utiliza la clase para una lista de páginas, me gustaría ir con el uso de C# 's mecanografiadas fuertemente recursos - se comportarán de la misma manera como su clase y que no tendrán que codificarlos a mano.)
Para la visibilidad pública preferiría 'static readonly' a' const' porque luego puede cambiar el valor después sin necesidad de volver a compilar. – mgronber
@mgronber: depende del contexto. En la mayoría de los contextos en los que me he desarrollado, si cambia un ensamblaje, termina recompilando clientes de ese ensamblaje de todos modos antes de usar la nueva versión. –