¿Cuáles son las mejores características de un marco de capa de datos para aplicaciones WPF/MVVM?

Question

Estoy creando un marco WPF/MVVM que genera el código para las clases modelo.

tengo la intención de tener para cada base de datos de la tabla/servicio web (por ejemplo, "Clientes") dos clases modelo:

• una clase del modelo singular (por ejemplo, "Cliente")
• y una clase de modelo plural (por ejemplo, "clientes")

El singular clase de modelo tiene todas sus propiedades (nombre, apellido, etc.), además de toda ella métodos que tiene sentido para una SINGULA por ejemplo, p. Save(), Delete(), CalculateSalary(), etc.

La clase de modelo plural tiene una colección de objetos de modelo singular, más los mismos métodos ya que también desearía realizar en un grupo de objetos singulares, p.ej Save(), Delete(), CalculateSalary(), pero también métodos particulares como Sort(), y métodos que lo hicieron muy fácil para ciertos grupos, p. LoadAllGoldCustomers(), o incluso LoadWithSql (sql string), etc.

que he hecho un marco como éste antes (PHP) y resultó ser muy fácil de entender y escribir código como este:

Customers customers = new Customers("all"); 
customers.CalculateSalary(); 

Un par de clases heredadas (elementos y elementos) sacaron la mayor parte del código de las clases individuales y plurales individuales para cada tabla de base de datos, lo que hizo un entorno muy limpio para programar.

Sin embargo, rara vez he visto otro las aplicaciones hacen esto división de clase de modelo singular/plural. En cambio, casi siempre hay una sola clase para cada tabla de base de datos, p. Customer y esta clase tiene cualquier método plural necesario, p. GetCustomers (sql string), etc.

acabo de notar en el WPF Model-View-ViewModel Toolkit 0.1 tutorial, tienen que hacer dos modelos de sus "modelos" de directorio dos clases:

• Customer.cs (sólo campos)
• (método de una lista Load()) CustomersDataSource.cs

Qué parece ser un concepto similar, sólo que la clase "plural" se llama un origen de datos.

Así que ahora estoy a punto de hacer otro marco basado en WPF/MVVM y puedo decidir cómo quiero estructurar las clases de modelo. Quiero que el marco sea:

• clara y fácil de programar en contra del modelo de vista, de ahí la clara separación de las clases del modelo singular y plural, que sólo debe tener para crear instancias de una clase singular o plural y llamar a un método en él y usted tiene sus datos.
• encaja muy bien con el patrón MVVM (que entiendo medios para mantener lo más simple posible, sólo tienen propiedades y métodos que el modelo de vista puede llamar, pero la aplicación no presenta ninguna-WPF específicos tales como INotifyProperityChanged)
• quieren mi capa de datos al se encuentra sobre cualquier fuente de datos, así que si uso LINQ-to-SQL, igual llamo a mis propias clases de modelo, y si quiero cambiar a guardar en Oracle, escribo una capa de adaptador de datos más baja para mis clases interactuar con eso.
• toma ventaja de LINQ de la mejor manera posible

Me gustaría recibir sus comentarios como los que se han desarrollado datalayers para marcos especialmente utilizando WPF/MVVM/Composite Application Library y qué características se encontró que funcionó mejor, o si ha trabajado con otros marcos tales como CSLA, Subsónico, etc. También, cualquier experiencia o ideas sobre cómo LINQ cambia/simplifica la construcción de una estructura de capa de datos. Gracias.

Answer 1

Wow. Es una pregunta difícil de responder sin tener un día para sentarse y hablar con usted. Pero aquí va una versión abreviada de todos modos.

En primer lugar, intentar portar un marco o cualquier característica de ese marco de un idioma a otro parece que quizás esté tratando de clavar una clavija cuadrada en un agujero redondo. Si bien no tengo dudas de que las funciones (por ejemplo, clientes y clientes) pueden ser portadas, ciertamente podría argumentar que no deberían ser portadas. Siguiendo con el cliente. Cálculo de Salario, también podría usar .NET y crear un método de extensión para IEnumerable que hiciera lo mismo, eliminando la necesidad de esa clase de Clientes. Me doy cuenta de que puede tener otras características también, pero eso es solo un ejemplo. Otro ejemplo es el uso de LINQ para ordenar IEnumerable.

En segundo lugar, personalmente he encontrado que tener los métodos de persistencia (por ejemplo, Guardar, Eliminar, etc.) dentro del objeto no funciona bien en un sistema grande, particularmente cuando se trata de WCF. Parece que funciona mejor en estos escenarios utilizar algún tipo de repositorio más adelante, lo que parece que también funcionaría bien con su punto de cambiar a Oracle en el medio del desarrollo.

También quiero estar totalmente en desacuerdo con usted sobre la posibilidad de encajar bien en MVVM. Para mí, el modelo de vista es el pegamento entre el modelo y la vista. No solo es probable que el modelo de vista necesite conocer la vista (por lo tanto, las características específicas de WPF), sino que desea que lo sepa. ICommand es una interfaz crítica para conocer el modelo de vista, y es uno de los ensamblados de WPF-y (WindowsBase, PresentationCore, PresentationFramework, no recuerdo cuál). Además, INotifyPropertyChanged también es fundamental para el enlace de datos y debe implementarse en todos los modelos de vista, y no tiene nada que ver con WPF (¿viene de System.ComponentModel, creo?).

Esa es mi granito de arena. Nuevamente, es realmente difícil explicar esto en una respuesta corta a su pregunta. Yo recomendaría usar el patrón por un tiempo antes de hacer un marco para él. ¡Buena suerte!