En primer lugar, no sé la razón de pasar por MVC y MVVM Al mismo tiempo, ¿Estás tratando de explorar MVVM o aprender MVC? Si alguna de estas direcciones es correcta, entonces no debe pisar la otra dirección. Modelo: es una clase que contiene datos, sus datos esencialmente necesarios para aparecer en su interfaz de usuario (ver, que es main.storyboard o xib o lo que sea).

Situación hipotética. Está creando una aplicación que recupera los datos meteorológicos más recientes de una API REST remota de código abierto, recupera los datos JSON, analiza los datos JSON en una vista de tabla / colección. Modelo: construiría estos objetos de datos, por ejemplo, el clima que tendría diferentes objetos de datos relacionados con el clima. Puede hacer la llamada de red dentro del modelo / o hacerlo en una capa de red independiente y devolverla al modelo. Entonces, finalmente, ViewController será como: Hola, modelo, obtenga los datos meteorológicos y dámelo, entonces el modelo sería como sí, señor procesamiento, hecho, tome estos datos. Entonces, el trabajo de ViewController es llenar solo estos datos usando métodos delegate / datasource. Espero que hayas entendido mi respuesta y si todavía eres ingenuo en MVC, diría que no intentes aprender ambos al mismo tiempo, un paso a la vez es un mejor proceso de aprendizaje en general porque construye una buena base para ti actual y el futuro potentes aplicaciones de iOS, ya que estos son los patrones de diseño básicos que necesitará.

Gracias por el A2A, ya que sé que estabas trabajando en iOS antes de dar respuestas algo centradas en iOS. Sin embargo, la teoría es la misma en general.

Asumiré que el Modelo es un objeto ObjC.

No sé si es MVC “adecuado” o no, pero mis controladores conocen los objetos del modelo, con frecuencia tienen una referencia directa a ellos. La parte “Notificaciones” normalmente se realiza a través de KeyValueObservation o, a veces, NSNotificationCenter (según cómo funcione realmente el modelo). No estoy muy emocionado con la API KVO de ObjC, por lo que normalmente uso la “biblioteca” KVO de Mike Ash porque hace que sea mucho más difícil seguir observando accidentalmente un objeto muerto (nunca es una buena idea).

Si tiene algún tipo de objeto o estructura Swift en lugar de un objeto ObjC, las cosas se vuelven más ad hoc. A veces omito el paso “Notificar”, hago una actualización, y luego sé que he actualizado las cosas y solo voy y miro el valor nuevamente. Esto es bastante lamentable, pero en un apuro normalmente funciona (a menos que otras cosas, entonces el Controlador pueda cambiar el modelo). También he “reinventado” la observación aquí agregando un protocolo para observar el modelo, y haciendo que el modelo rastree un conjunto de “observadores” y llame métodos de protocolo variables cuando cambian los valores. Esto hace que el Controlador “se vea mejor”, y es más robusto frente a los cambios generados por múltiples fuentes de cambios. Sin embargo, es más doloroso escribir.

En cuanto a las “actualizaciones” que son solo llamadas de método en el modelo. Como “model.damage (5)”, o “model.retalPeriodExpired ()”, o “model.weight + = 5”.

Cuando habla del controlador y la vista, eso normalmente es algo que configura con InterfaceBuilder. El “envía acciones de usuario” son eventos conectados a IBActions. Todo esto se puede hacer sin InterfaceBuilder, pero este es uno de sus pocos puntos fuertes, es una pena no usarlo.

El controlador que actualiza la vista es un poco más complejo, tal vez. En Mac (no iOS) se pueden usar enlaces de valor en IB y no escribir código en absoluto. Si lo haces bien, es increíble. Si te equivocas, es difícil depurar problemas. Leyendo entre líneas, creo que Apple desearía nunca haberlo hecho porque nunca llegó a iOS …

Muchas veces harás algo como observar una propiedad de modelos foo en el controlador y meterla en fooLabel.text. Eso siempre me ha parecido un código aburrido … por eso existen enlaces en macOS … excepto que son terribles cuando no funcionan y es (quizás) por qué no existen en iOS.

El controlador en teoría debería ser simple, trate de mantener la lógica de presentación en la vista y el código de negocio (o modelo mundial) en el modelo. En la práctica, siempre parece que el código del controlador de la gente se hincha cada vez más con el código que pertenece a otra parte. Así que manténgase atento a eso y empuje ese código de regreso a donde pertenece. ¿Sigue viendo el código de vista en el controlador? Tal vez realmente necesites una vista personalizada y más lógica en eso …

Quiero responder la pregunta con pseudocódigos, digamos que necesitamos una lista de carrito de compras

• el modelo (solo los datos)

clase CartLine {
int LineId,
int OrderId,
Cantidad decimal,
Precio de unidad decimal
Línea decimal total
}

• El modelo de vista contiene los modelos y propiedades.

clase CartLineViewModel {
List CartLines;
decimal CartTotal;
int ItemCount;
}

• el controlador (inicia este modelo de vista mediante los datos de db o etc.)

clase CartController {
var vm = nuevo CartLineViewModel {
CartLines = nueva Lista {
nueva CartLine {1,1,3,1.2,3.6},
nueva CartLine {2,1,2,2,4},
},
CartTotal = 7.6,
ItemCount = 5
};
}

• la vista (muestra estos modelos de vista iniciados)

@use CartLineViewModel;

Hay un elemento @ model.ItemCount en la lista

@foreach @ model.CartLines, etc.

Como puede ver aquí, el modelo, como meta nada más, no habla con nadie que acaba de pasar

Aclamaciones,