A medida que aumenta el código comercial, el controlador de visualización se infla cada vez más, lo que dificulta el mantenimiento posterior. Cada vez que agrega o cambia, la forma más fácil es agregar o cambiar la base original, pero esto no es correcto. Por supuesto, cada vez que lo cambia, necesita reconstruirlo una vez. Aunque es ideal, es no realista. Este artículo analiza varios patrones arquitectónicos para reducir la cantidad de código de cada clase sin reducir la capacidad de lectura.
Los pasos de desarrollo tradicionales son crear un nuevo vieController, encapsular los datos en un modelo de datos a través de la solicitud de la interfaz y representarlo en la celda de la vista de tabla. El viewController se encarga de la adquisición y el procesamiento de los datos, así como de la carga de la página, pantalla y lógica de interacción. El código general está todo en el superior viewController
1 MVC
En el modo MVC, la adquisición de datos, la encapsulación y la lógica de procesamiento se pueden colocar en el modelo, los relacionados con la vista se colocan en la vista, y el controlador solo necesita procesar la sincronización de datos y ver los eventos de operación, lo que puede reducir la cantidad de código en el controlador, mientras que la vista y el modelo también se pueden reutilizar, pero MVC también tiene problemas
Los ejemplos son los siguientes
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
BlogCellHelper *cellHelper = self.blogs[indexPath.row];
BlogTableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:ReuseIdentifier];
cell.title = cellHelper.blogTitleText;
cell.summary = cellHelper.blogSummaryText;
cell.likeState = cellHelper.isLiked;
cell.likeCountText = cellHelper.blogLikeCountText;
cell.shareCountText = cellHelper.blogShareCountText;
//点赞的业务逻辑
__weak typeof(cell) weakCell = cell;
[cell setDidLikeHandler:^{
if (cellHelper.blog.isLiked) {
[self.tableView showToastWithText:@"你已经赞过它了~"];
} else {
[[UserAPIManager new] likeBlogWithBlogId:cellHelper.blog.blogId completionHandler:^(NSError *error, id result) {
if (error) {
[self.tableView showToastWithText:error.domain];
} else {
cellHelper.blog.likeCount += 1;
cellHelper.blog.isLiked = YES;
//点赞的业务展示
weakCell.likeState = cellHelper.blog.isLiked;
weakCell.likeCountText = cellHelper.blogTitleText;
}
}];
}
}];
return cell;
}
复制代码La función similar cambia la fuente de datos a través del evento de botón de la celda, que acopla la capa de vista y la capa de modelo, lo que no puede lograr el propósito de desacoplar la vista y el modelo que esperamos. Además, para interfaces complejas o procesamiento de datos complejo, la Vista, el modelo se vuelve hinchado.
2.MVP
La desventaja de MVC es que no distingue entre la lógica comercial y la presentación comercial, lo que es muy poco amigable para las pruebas unitarias. MVP está optimizado para las deficiencias anteriores. También aísla la lógica comercial y la presentación comercial, y el correspondiente se convierte en MVCP.
Las funciones de M y V permanecen sin cambios, el C original solo es responsable del diseño y toda la lógica comercial se transfiere a la capa P. Después de que la capa P haya procesado la lógica empresarial, si desea cambiar la visualización de la vista, puede implementarla a través de devoluciones de llamada, lo que puede reducir el acoplamiento y probar la lógica empresarial de la capa P por separado.
Como se puede ver en la imagen, sobre la base de MVC, viewController contiene la capa de vista y la capa Presente, y las capas presente y modelo interactúan para obtener datos, procesar los datos y mostrar la capa View a través del proxy. En la subunidad de la vista, tomando como ejemplo la UITableCell común, la celda no necesita obtener todo el modelo de datos, sino que solo necesita varios valores de atributo en el modelo de datos, en este caso una capa de Present se agrega entre la celda y el modelo de datos, y se agregan la celda y el modelo de datos.El modelo de datos se desacopla y la celda se puede reutilizar en un sentido verdadero.
3.MVVM
MVVM se desarrolla sobre la base de MVP, entonces, ¿por qué deberíamos diseñar este modo?Tome como ejemplo, haga clic en el botón de la celda ---> llame a la lógica similar de P ---> Después de que el similar tenga éxito, P cambia El Los datos de M ---> P vuelven a llamar al método proxy de la celda para cambiar la visualización de la celda (si el Me gusta tiene éxito, la cantidad de Me gusta aumentará en 1 y la cantidad de Me gusta se volverá roja; de lo contrario, el el número de Me gusta no cambiará y el color no cambiará) Lo anterior es un El proceso completo del evento se puede ver que se completa en cuatro pasos, y el estado de P debe sincronizarse con la vista cada vez. son muchos eventos, es muy molesto escribir de esta manera. ¿Existe un mecanismo simple para sincronizar el comportamiento y el estado de vista con el comportamiento y el estado de P?
La respuesta es el mecanismo de unión de MVVM. MVVM a menudo se implementa mediante RAC en la implementación y no se ampliará aquí.
MVVM各层的职责和MVP的类似，VM对应P层，只是在MVVM的View层多了数据绑定的操作