Recuerda que en la informática un error casi siempere puede tener más de una resoluciones, por lo tanto aquí te mostraremos lo más óptimo y eficiente.
Solución:
La fuente de datos proporciona los datos, el delegado proporciona el comportamiento.
En MVC, la fuente de datos está en la capa del modelo y el delegado está en la capa de control.
En realidad, pensándolo bien, la fuente de datos suele ser el controlador que está más abajo, más cerca del modelo. No creo que haya usado nunca un objeto modelo como fuente de datos.
Los patrones de delegado y origen de datos son en gran medida independientes y ortogonales:
El patrón de delegado es muy común en Cocoa y permite que un delegado (cualquier instancia que implemente el protocolo de delegado informal antes de OS X 10.6, o el delegado formal @protocol en 10.6 y posteriores) para modificar el comportamiento de una instancia de objeto. Este patrón se usa a menudo en lugar de subclasificar: en lugar de subclasificar una clase para cambiar su comportamiento, proporciona un delegado que responde a los métodos apropiados. Las clases que usan delegados envían mensajes a su delegado en eventos contratados. La API entre la clase y el delegado está definida por la clase y es diferente para cada clase que usa el patrón, pero la API generalmente consiste en mensajes que le preguntan al delegado cómo manejar un evento en particular. Una ventaja del patrón de delegado sobre las subclases es que una clase puede implementar múltiples protocolos de delegado, lo que permite que sus instancias actúen como delegado para múltiples clases. De manera similar, una instancia de objeto puede ser el delegado de varios otros objetos (por lo tanto, la mayoría de las API delegadas pasan el objeto como primer argumento a cada mensaje en la API). El patrón de delegado no es tan común en otros marcos de interfaz de usuario (aunque Qt usa el patrón de delegado en su marco de modelo / vista), y es no lo mismo que los delegados .Net / CLR que son esencialmente punteros de función mecanografiados.
El patrón de fuente de datos lo utilizan a menudo NSView subclases en Cocoa que tienen datos de estado complejos como NSBrowser, NSTableView, NSOutlineView, etc. El protocolo de origen de datos define una API que las instancias de estas (y otras) clases pueden usar para obtener los datos para mostrar en la vista. Aunque el NSController y las arquitecturas Cocoa Bindings han reemplazado muchos usos del patrón de fuente de datos, sigue siendo común y muy poderoso. Al igual que el patrón de delegado descrito anteriormente, parte de su poder proviene de que un objeto puede actuar como fuente de datos para múltiples instancias de uso de fuentes de datos (y posiblemente incluso instancias de múltiples clases que tienen diferentes protocolos de fuente de datos). El patrón de fuente de datos se usa comúnmente en otros marcos de UI, como Qt (en el marco Modelo / Vista donde el modelo es análogo a la fuente de datos) y WPF / Silverlight (donde la fuente de datos puede ser más análoga al modelo de vista ).
Suponga que tiene 3 vistas de tabla. Para perros, gatos y pájaros. Al tocar en cada celda, se mostraría una nueva pantalla con la foto ampliada de la misma.
Para diseñar esto, deberá crear 3 fuentes de datos independientes para perros, gatos y pájaros. Básicamente necesitas tres matrices.
Sin embargo, no necesita 3 delegados de vista de mesa. Porque el comportamiento de las vistas de tabla es el mismo. Todos ellos simplemente presentan un viewController y lo llenan con un UIImage. Esto es sólo true si su delegado está escrito de forma genérica, es decir, no hay código específico de perro, gato o pájaro en el delegado.
Habiendo dicho eso, podría abstraer el perro, gato, pájaro de la fuente de datos, pero mi respuesta fue solo un ejemplo artificial. Algunos objetos personalizados son demasiado complejos para usar la misma estructura, de ahí la necesidad de tener 3 fuentes de datos.
Respuesta anterior:
Antes de responder la pregunta, debe comprender mejor el patrón de diseño de delegación: Permítanme comenzar con una pregunta:
Por defecto, un TableView es así:
¿Cómo sabe un UITableView cuántas celdas presentar? ¿Qué presentar en cada celda?
- Por sí mismo, no lo sabe.
- Pide a otra clase que informar Se trata de la cantidad de celdas y qué celda devolver (qué imagen de celda, título de celda, subtítulo de celda, etc.) se valora a sí mismo. Por lo general, ve un tableView (clase de delegación) dentro de un ViewController (clase de delegado)
- Este concepto de una clase preguntando a otra se conoce como ¡delegación!
Ahora que sabe qué es Delegación, para responder a la pregunta real del OP:
Es sobre todo una GRAN cuestión de diferencias semánticas.
Si solo va a usar (no crear su propio protocolo) los delegados y las fuentes de datos de la fundación, entonces realmente no le importa. Sin embargo, si tiene la intención de escribir protocolos personalizados, comprenderlos le ayudará a escribir (y con mayor importancia leer, refractor) código mejor.
Desde el punto de vista de un desarrollador, ambos se ocupan de la interacción entre los delegadosEn g clase y clase delegada.
Fuente de datos
Una fuente de datos es casi idéntica a un delegado. La diferencia está en la relación con el objeto delegante. En lugar de delegar el control de la interfaz de usuario, una fuente de datos es el control delegado de los datos. El objeto que delega, típicamente un objeto de vista como una vista de tabla, tiene una referencia a su fuente de datos y ocasionalmente le pide los datos que debería mostrar. Una fuente de datos, como un delegado, debe adoptar un protocolo e implementar como mínimo los métodos requeridos de ese protocolo. Las fuentes de datos son las encargadas de gestionar la memoria del objetos modelo
dan a la vista que delega.
En términos simples:
DataSource se ocupa principalmente de qué y por lo general hace sus cosas tras la inicialización. El delegado se ocupa principalmente de cómo y alimenta Tienes algunos parámetros para dar un comportamiento determinado, es decir, si el usuario hace clic en esto … ¿qué debería suceder? si robaron … ¿qué debería pasar?
Como ejemplo para tableView:
Fuente de datos
¿Qué tiene dentro? ¿Qué tipo de celda estoy presentando? cellForRowAtIndexPath.
¿Cuál es el título de la sección? titleForHeaderInSection
¿Cuántas células son? numberOfRowsInSection
Y por lo tanto usualmente regreso valores. Para los delegados es más común ser de tipo void.
Métodos de origen de datos
func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell // return a cell ie UITableViewCell
func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int // return a number ie an Int
func tableView(tableView: UITableView, titleForHeaderInSection section: Int) -> String? // return the title ie a String
Métodos delegados
func tableView(tableView: UITableView, didSelectRowAtIndexPath indexPath: NSIndexPath)
func tableView(tableView: UITableView, willBeginEditingRowAtIndexPath indexPath: NSIndexPath)
func tableView(tableView: UITableView, willBeginEditingRowAtIndexPath indexPath: NSIndexPath)
Obviamente, elegí selectivamente ya que algunos métodos de fuente de datos no regresan y algunos métodos delegados regresan
Delegar
¿Qué debo hacer / qué ‘forma de comportamiento’ debo usar después de terminar la visualización del pie de página? ¿Quieres que muestre una alerta?didEndDisplayingFooterView
¿Voy a tener el tipo de accesorio que le da al celular algunas características adicionales? accessoryTypeForRowWithIndexPath