Necesita algunas aclaraciones sobre el Modelo del lado de MVC

Question

Supongo que tendría alguna explicación muy buena en algunos modelos de conceptos relacionados.

1. En general el modelo, como se describe por marcos como Robotlegs jugar el papel de un estado de la aplicación del titular, o de un estado del dominio titular?Yo pensaba originalmente que los modelos son completamente basada en dominio, yo.e UserModel, LocationModel, que juegan el mismo papel que las clases DAO de jugar en el servidor.El más código fuente estoy buscando a pesar de que, cuanto más veo cosas como UserAccountModel, ShoppingCartModel, etc, llena de propiedades y métodos relacionados con el estado de la aplicación cliente, no del dominio del estado.

2. Veo que la gente no se molestan en añadir complejas relaciones de la VO clases, es decir,si un Usuario tiene un montón de fotos, las fotos de la colección es, obviamente, omitido de la UserVO clase.En lugar de eso, un montón de PhotoVO objetos se carga desde el servidor cada vez que sea necesario, basándose en una llamada de servicio con el ID de usuario.Es que algún tipo de regla general - en general mantener a VOs como "desnudo" como sea posible?No es que aumente el número de llamadas que se debe realizar en el servidor para recuperar todos los datos?Por otra parte, no se que fragmentan el modelo de dominio en general?(una entidad de clase de Usuario en el servidor siempre tendrá una fotos de la propiedad)

3. Con tantas llamadas al servidor, es normal para recuperar algunos de los objetos que ya puede estar en el cliente de almacenamiento.¿tiene sentido hacer una caché del lado cliente, y comprobar si el objeto que se va a recuperar está ya allí, o en general, la sobrecarga de conseguir que otra vez será pagado por los beneficios de obtener un totalmente sincronizado objeto desde el servidor.De lo contrario, todos los objetos almacenados en la caché del lado cliente debe ser atendido cuando se produce un cambio.Yo, personalmente, creo que la sobrecarga de conseguir un objeto desde el servidor, que ya han sido recogidos antes no es tan grande.Mejor frescas y los datos sincronizados diría yo.

Answer 1

No creo que su pregunta sea responsable, porque muchas de las respuestas son "depende". Depende de la aplicación que esté construyendo y de las necesidades de la interfaz de usuario.

Realmente no entiendo su distinción entre "estado de dominio" y "estado de aplicación". Sin embargo, creo que cualquier clases de estilo de "valor de valor" implementado en la interfaz de usuario debe centrarse en mantener el estado de opiniones específicas. Es extremadamente raro que una sola vista sea una relación única con las tablas de bases de datos. Como tal, los objetos de datos de la interfaz de usuario pueden no ser idénticos a los objetos de datos del lado del servidor. Aunque, es muy común que asigne objetos de interfaz de usuario a objetos del lado del servidor usando AMF. Pero, no significa que cada objeto de la interfaz de usuario esté implementado del lado del servidor y cada objeto del servidor se implementa en la interfaz de usuario.

Veo que las personas no se molestan en agregar relaciones complejas a las clases de VO,

No estoy seguro de dónde ves eso; A menudo haré exactamente esto. Sin embargo, depende de lo que se supone que debe mostrar la vista. Si la vista no muestra muchas fotos relacionadas con el usuario, no haré una llamada remota para recuperar la información del usuario con todas sus fotos.

Con tantas llamadas al servidor, es normal obtener algunos objetos que ya puedan estar en el almacenamiento del cliente.

Eso depende. Diría que las aplicaciones que escribo, las llamadas al servidor se realizan según sea necesario; y se hacen intentos para limitarlos según corresponda. Si ya obtuve datos y los tengo en caché en el cliente, voy a intentar usar ese caché en lugar de recuperar los datos nuevamente.

Reafirmaré mi evaluación original: creo que las respuestas a la mayoría de sus preguntas dependen de la situación y dependen de la aplicación. Parece comenzar con generalizaciones demasiado amplias sobre cómo se hacen las cosas. Sin embargo, no creo que sean verdades universales. La lucha del desarrollador sobre los problemas de arquitectura de aplicaciones todo el tiempo.