2011-10-30 13 views
9

A menos que malinterprete: la mayoría de los artículos que leí en MVVM explican el modelo en MVVM como el dominio/business-logic de pieza, pero lo que me desconcierta es que MVVM es un patrón de capa de presentación y la capa de presentación no mantener la lógica de negocios en su totalidad. ¿Pueden algunos ayudarme a entender cómo la lógica de dominio en la capa de negocios se asigna al modelo en la capa de presentación? ¿El modelo en MVVM en realidad es una DTO? Agradecería que alguien pudiera ayudar a explicar con un ejemplo cómo la capa empresarial se asigna a un modelo de MVVM en SOA (la lógica de negocios se ubica detrás de un servicio web). Gracias.El modelo en MVVM

+0

Vea mi respuesta aquí y los comentarios que la gente le ha dado. Creo que con demasiada frecuencia MVC y MVVM son malinterpretados y la gente cree que los Modelos y Controladores están reemplazando DataModel y Business Logic. En mi opinión, tanto MVVM como MVC solo se encuentran en el nivel UI para mantener la composición de la interfaz de usuario separada por alguna manipulación básica de Entidades u otra lógica UI, así que creo que mi respuesta se aplica tanto a MVC como a MVVM. –

+0

Lo siento, no puedo ver ninguna URL, ¿puedes editarla y volver a publicarla? Gracias. –

+0

lo siento, lo olvidé: D http://stackoverflow.com/questions/7474267/mvc3-and-entity-framework/7474357#7474357 –

Respuesta

1

MVVM, como MVC, es solo una forma de presentación separada en la que se intenta separar las preocupaciones entre la parte de la aplicación relacionada con la lógica y el estado de la interfaz de usuario y la parte de la aplicación relacionada con la lógica y estado relacionados con el dominio comercial. Entonces, MVVM realmente no dicta nada sobre la forma que toma la parte del Modelo, siempre que esté separada de las preocupaciones de presentación.

El modelo no está acoplado o es dependiente de ningún modo en los aspectos de presentación de la aplicación, pero más allá de eso hay muchas maneras diferentes de implementar la parte "M" de la tríada. En particular, no tiene que mapear a un solo objeto: podría significar interactuar con un servicio que devuelve DTO, podría significar publicar y suscribirse a mensajes en un bus de mensajes o podría significar recuperar objetos de dominio que representan entidades en su dominio, invocando métodos sobre ellos y luego persistiéndolos.

Lo que es realmente único sobre el patrón MVVM es el rol de ViewModel, ya que su propósito es representar el estado de la UI de una manera que pueda ser consumida por las tecnologías View que tienen amplias capacidades de enlace de datos. Sin un soporte rico en enlaces de datos, se utilizaría una forma diferente de presentación separada, como MVC o MVP, pero la parte "M" podría seguir siendo la misma porque, por definición, es independiente de la tecnología UI. Ese es el factor importante.

0

Muy a menudo El modelo está encapsulado por ViewModel. Debe separar Model y ViewModel cuando, por diseño, podría ser que solo ViewModel utiliza diferentes modelos. Pero realmente este es un caso raro, por lo que ViewModel puede trabajar directamente con los servicios.

Si solo ViewModel puede servir diferentes tipos de Modelos que podrían ser sustituidos uno por uno - introduzca una capa separada de Modelos, resúmalos por interfaces e inyéctelos en ViewModels apropiados; de lo contrario, View and ViewModel es suficiente.

1

El modelo en MVVM no es en absoluto el DTO. DTO es el Objeto Transferible de Datos. Es más como las clases de entidad. Básicamente se usa para transferir datos de una capa a otra; como la capa de presentación a la capa de negocios o la capa de negocios a la capa de acceso a datos.

Y el modelo consiste principalmente en la lógica de negocios. La capa de presentación a través del modelo de vista llama a la lógica de negocios del modelo cuando sea necesario.

Cuestiones relacionadas