MVC: ¿Modelos completamente poblados o modelos parcialmente llenos?

Este me ha perseguido por tanto tiempo. Al hacer programación MVC, ¿cuál crees que es la mejor práctica de programación? ¿Debería uno usar modelos completamente poblados o parcialmente llenos, especialmente cuando sé que para esta tarea en particular necesitaré solo 2 campos del objeto modelo que tiene otros 5?

A veces parece criminal llenar una lista de 20 objetos modelo con todos los valores de la base de datos cuando sabes que solo necesitarás unos pocos.

Por supuesto, el modelo parcial significa que tendrá que escribir un método más en su DAO aparte del que obtiene todo. ¿Qué significa más código para mantener?

Por otro lado, sacar todo de DB con modelos completamente poblados significa que un método sirve para todos, pero esto obviamente le dará algo de sobrecarga de rendimiento.

Puedo ver que ORM (como Hibernate o ActiveRecord of Rails) favorece las tendencias en la programación MVC y las bases de datos como los modelos completos BigTable de Google es una tendencia aceptada. Pero, ¿qué pasa si todavía estás usando un buen JDBC?

El hardware es barato, el desarrollo es costoso. ¿Es eso realmente cierto incluso cuando la aplicación necesita escalar a unos cientos de miles de solicitudes por hora?

Tienes dos opciones:

1) Deje algunos campos en el modelo sin llenar

2) Cree un modelo "lite" adicional para su situación específica

Cuál elegir depende de las dos cosas nuevamente:

a) ¿Cuántos campos del modelo "completo" serán ignorados?

b) Con qué frecuencia se instanciará este modelo "lite"

Si solo hay un par o más de campos que se pueden completar, está bien ir con 1).

Si b) es solo una situación individual excepcional, quizás no tenga sentido crear un modelo adicional solo para un caso de uso.

Otro enfoque es definir un modelo "lite" y heredar el modelo "completo" de él.

Si su vista solo necesita 2 propiedades del modelo, entonces (probablemente) tenga el modelo incorrecto para ese caso de uso. Me gustaría crear un modelo que se adapte a la vista, guardar las búsquedas de DB adicionales y solo completar los datos que necesita. Si una vista posterior necesita más detalles, entonces tiene que preguntar, ¿obtengo los datos adicionales más tarde o debo obtenerlos por adelantado ...

Como alternativa, podría considerar algún tipo de evaluación diferida, de modo que los valores se completen cuando los necesite. Esto puede funcionar bien, pero obviamente es más trabajo y puede terminar causando múltiples viajes de ida y vuelta a la base de datos, lo que no es genial si terminas haciéndolo mucho.

Dicho esto, si básicamente está seleccionando algunos campos adicionales de una tabla o vista, entonces el costo de obtener esos datos adicionales es, a todos los efectos, cero (OK, hay más bytes en el cable, pero es probable que los mayores costos sean estar en la creación y derribo de una conexión), por lo que si existe la posibilidad de que necesite algunos datos adicionales, probablemente llenaré el modelo por completo una vez que esté satisfecho de tener el modelo correcto .

El hardware es barato, pero ninguna cantidad de hardware puede hacer que un mal diseño funcione bien.

El modelo no es un DAO.

Y otra cosa: si dice que tiene 20 modelos (clientes, según su ejemplo), entonces ese no es un modelo MVC. El modelo de dominio no se asigna directamente a una sola fila de tabla. En cambio, debe ser responsable de todas las operaciones realizadas con sus "clientes".

En su ejemplo, "Cliente" no es un modelo de dominio, sino solo un objeto dentro del modelo.

En cuanto a la interacción con la base de datos, esa responsabilidad debe delegarse en un objeto de mapeador de datos , que debe saber cómo almacenar y buscar sus instancias de clase de Cliente.