¿Cómo diseñaría una aplicación de escritorio en C# 3.0

Question

? He creado una aplicación de escritorio simple en C# 3.0 para aprender C#, wpf y .Net 3.5. Mi aplicación esencialmente lee datos de un archivo csv y los almacena en una base de datos SQL server CE. Yo uso sqlmetal para generar el código ORM para la base de datos. Mi primera iteración de esta aplicación es fea como el infierno y estoy en el proceso de refactorización.

Lo que me lleva a mi pregunta. ¿Cómo diseñarías una aplicación de base de datos de escritorio en C#? ¿Cuáles son las mejores prácticas?

¿Creas una Capa de abstracción de base de datos (DAL) que utiliza el código generado sqlmetal? ¿O es el código generado suficiente de una abstracción?

Si usa el patrón DAL, ¿lo convierte en un elemento único o estático? ¿Utiliza el patrón View-Model-ModelView con el patrón DAL?

Disculpas si esto parece una larga pregunta abierta, pero hace mucho tiempo que reflexiono sobre esto. Veo muchos ejemplos sobre cómo diseñar una aplicación n-tier empresarial en C#, pero no tanto sobre la arquitectura de aplicaciones de escritorio independientes.

Answer 1

Me gustaría empezar con la Composite Application Guidance for WPF (tos PRISM tos) del equipo de Microsoft P P &. Con la descarga viene una gran aplicación de referencia que es el punto de partida para la mayoría de mi desarrollo de WPF en la actualidad.

El DotNetRocks crew acaba de entrevistar Glenn Block y Brian Noyes acerca de esto si está interesado en saber más de ellos.

Mejor aún, Prism no es tan pesado como el CAB, si está familiarizado con eso desde los días de WinForms.

Answer 2

Antes de diseñar algo, debe definir los requisitos para su aplicación.
Es un error común de los desarrolladores principiantes: comenzar a escribir código antes de pensar en cómo funcionaría. Mi consejo será tratar de describir alguna característica de tu aplicación. Te ayudará a sentir cómo se debe implementar.

En cuanto a los recursos de aprendizaje útiles, le recomendaría echar un vistazo a CompositeWPF, es un proyecto diseñado específicamente para enseñar a los desarrolladores las mejores prácticas de desarrollo de aplicaciones de escritorio.

Answer 3

La respuesta es "depende" como siempre.

Algunas cosas que debe tener en cuenta: Es posible que desee convertir esta aplicación de cliente gorda en una aplicación web (por ejemplo) en algún momento. De ser así, debe asegurarse de mantener la separación entre la capa de negocios (y abajo) y la presentación. La forma más sencilla de hacerlo es asegurarse de que todas las llamadas a la lógica empresarial pasen por una interfaz de algún tipo. Una forma más compleja es implementar una configuración completa de MVC.

Otra cosa que puede considerar es hacer que la capa de acceso a datos sea independiente de la lógica de negocios y la interfaz de usuario. Con esto quiero decir que todas las llamadas desde la lógica de negocios al DAL deberían ser genéricas "obtener estos datos" en lugar de "obtener estos datos de SQL" o incluso peor "ejecutar esta declaración de SQL". De esta forma, puede reemplazar su DAL por uno que acceda a una base de datos diferente, archivos XML o incluso algo desagradable como archivos planos.

En resumen, separación de preocupaciones.Esto le permite crecer en el futuro agregando una IU diferente, segmentando las tres áreas en su propio nivel o cambiando la tecnología relevante.

Answer 4

Yo diría que sí, podría estructurarse fácilmente para aplicaciones más pequeñas. Hay una curva de aprendizaje para comenzar, pero sinceramente, me ayudó a entender WPF mejor que intentar comenzar de cero. Después de comenzar un proyecto con CompositeWPF y luego comenzar otro proyecto sin él, ¡me encontré intentando duplicar funciones de CompositeWPF por mi cuenta porque me perdí esas características! :)

Answer 5

Comenzaría con la serie Build Your Own Cab de Jeremy Miller.

Fui uno de los primeros en adoptar CAB. Aprendí mucho de profundizar en esa tecnología y leer todos los blogs de .NET sobre arquitectura de aplicaciones.

Pero recientemente tuve la oportunidad de comenzar un nuevo proyecto, y en lugar de utilizar CAB fui con StructureMap & NHibernate y tomé prestados algunos de los patrones que utiliza Jeremy (en particular, su forma de manejar la agregación de eventos). El resultado fue un marco realmente simplificado, hecho a mano que hace todo lo que necesito y me encanta trabajar con él.

En cuanto a los detalles de su pregunta: uso un repositorio para el acceso a los datos. Inicialmente escribí algunos códigos ADO.NET y usé lectores de datos y mapeé mis objetos. Pero eso se hizo viejo muy rápido, así que agarré NHibernate y estaba realmente contento. Los repositorios usan NHibernate para el acceso a los datos, y mis necesidades de acceso a los datos son bastante simples en esta aplicación en particular.

Tengo una capa de servicio (expuesta a través de WCF, canales dúplex) que utiliza los repositorios. Mi aplicación es básicamente cliente-servidor con actualización en tiempo real (y sé que su pregunta era solo sobre clientes, pero usaría las mismas tecnologías y patrones). O

n del lado del cliente Utilizo MVP con StructureMap para IoC y algunas estrategias de agregación de eventos muy simples para comunicaciones entre clases. Codigo las interfaces para casi todo. La única otra cosa que hice fue tomar prestado del CAB la idea de un "Espacio de trabajo" flexible para mostrar dinámicamente las vistas. Sin embargo, escribí mi propia interfaz de espacio de trabajo e implementé mi propio DeckWorkspace y TableWorkspace para usar en mi aplicación (estas eran cosas realmente simples de escribir).

Muchas de mis decisiones en esta aplicación más reciente fueron el resultado de la experiencia y el dolor que sentí al utilizar otros marcos y herramientas. Tomé decisiones diferentes esta vez. Quizás la única forma de entender realmente cómo diseñar una aplicación es sentir el dolor de hacerlo mal de antemano.