2008-11-05 10 views
14

¿Cuál es la mejor manera de estructurar una aplicación VB.NET Windows Forms para que el código se pueda reutilizar y la aplicación se pueda extender fácilmente?Cómo estructurar aplicaciones de Windows Forms de VB.NET

Solía ​​crear muchos formularios nuevos. Esto condujo a muchos códigos y formas repetidos que hicieron cosas similares.

Ahora, para formularios que realizan trabajos similares, como ver/editar/eliminar elementos de una tabla de base de datos específica, creo un formulario con los controles necesarios, haga que el formulario cree una instancia de una clase con parámetros como colección de los controles y una cadena que contiene el nombre de la tabla de la base de datos. Entonces los controles individuales llaman a las funciones de la clase.

Los formularios avanzados heredarán y ampliarán esta clase de formulario básico.

  1. ¿Ya se ha hecho trabajo en esta área?
  2. ¿Hay libros/artículos disponibles que discutan las opciones disponibles sobre este tema?

Respuesta

4

Tuve un gran éxito con este patrón Passive Screen.

En mi opinión, el gran problema de la arquitectura tradicional de MVC es que las personas importan demasiado en las clases de formularios. Esto aumenta la cantidad de pruebas manuales que tiene que hacer.

Cuantas más pruebas automatizadas puede hacer después de compilar, más errores detectará en su escritorio. En una aplicación compleja, los efectos secundarios incluso de cambios menores ocurren con demasiada frecuencia.

El truco para resolver esto es hacer un ensamblaje de controlador al que haga referencia el ensamblado de formularios (o EXE). Cada formulario tiene una clase correspondiente en el conjunto. Al hacer clic en un botón se llamará al ThisForm.ThisButton(<args>), que luego disparará objetos más abajo en su marco. Cada formulario implementa una interfaz para que, si la clase de controlador necesita información adicional del formulario, tiene una interfaz para recuperarla.

Luego, para su unit testing simula un operador que realiza operaciones complejas al implementar clases ficticias para disparar eventos y alimentar información a las clases de controlador. Las clases de controlador no conocen ninguna diferente ya que las clases ficticias implementan todas las interfaces esperadas.

Hay una excepción importante y eso es para diálogos triviales. Para los cuadros de diálogo que tienen algunas casillas de verificación siento que esta organización es excesiva. Uso el command pattern mucho. Entonces, en el ensamblaje donde defino los objetos de comando, pongo el diálogo SIMPLE asociado con ese comando. Qué tan simple tiene que ser un diálogo para obtener este tratamiento depende de usted.

Me gusta estructurar mis aplicaciones de la siguiente manera.

  • Utilidad - Se trata de un montaje que tiene cosas que utilizo todo el tiempo - Las funciones matemáticas, función de archivo, etc.

  • Objetos - Esto tiene los objetos específicos que estoy usando para esta aplicación.

  • UIFramework - Define todas las interfaces de formulario y controlador.

  • Comandos - Esto tiene todos los objetos Command que manipulan mis objetos de aplicación.

  • UI - Objetos que implementan las interfaces de controlador

  • EXE - Formas que implementan la interfaz de forma y llama a los objetos del controlador.

3

Es posible que desee comprobar un popular CSLA Framework de Rocky Lhotka. Proporciona una forma muy estructurada de implementar objetos comerciales para que pueda mantener el código que no pertenece a la UI fuera de sus formularios. Más allá de solo separar su lógica de negocio, proporciona un nivel integrado de deshacer, validación, seguridad, soporte de enlace de datos, etc.

La única queja más comúnmente dirigida a CSLA es que dificulta el desarrollo basado en pruebas, de modo que puede ser algo a considerar también.

3

Algo que puede ayudar mucho es el uso de User Controls. Con los controles del usuario puede reutilizar la misma IU en diferentes formas. Además, puede tener muchos controles de usuario en un formulario, así que si tiene un formulario con un tabcontrol que tiene 5 pestañas, el contenido de cada pestaña podría ser un control de usuario, por lo que en lugar de tener cientos de controles todos mezclados en una sola forma , cada control de usuario tiene sus propios controles y lógica de validación, y usted termina con solo seis controles en el formulario: el tabcontrol y los 5 controles de usuario.

Esto no ayuda a separar el código de UI de la lógica de la aplicación, pero le permite tener entidades pequeñas y estructuradas en lugar de formularios con miles de líneas de código.

Cuestiones relacionadas