¿Cómo puedo separar la interfaz de usuario de la lógica de negocios sin dejar de mantener la eficiencia?

Digamos que quiero mostrar un formulario que represente 10 objetos diferentes en un cuadro combinado. Por ejemplo, quiero que el usuario elija una hamburguesa de 10 diferentes que contienen tomates.

Como quiero separar la interfaz de usuario y la lógica, tendría que pasarle al formulario una representación de cadena de las hamburguesas para mostrarlas en el cuadro combinado. De lo contrario, la interfaz de usuario tendría que cavar en los campos de objetos. Luego, el usuario elegiría una hamburguesa del cuadro combinado y la enviaría de nuevo al controlador. Ahora el controlador tendría que encontrar nuevamente dicha hamburguesa en función de la representación de cadena utilizada por el formulario (¿tal vez una ID?).

¿No es eso increíblemente ineficiente? Ya tenías los objetos de los que querías elegir uno. Si envió al formulario los objetos completos y luego devolvió un objeto específico, no tendría que volver a encontrarlo más adelante ya que el formulario ya devolvió una referencia a ese objeto.

Además, si me equivoco y realmente debe enviar todo el objeto al formulario, ¿cómo puedo aislar la interfaz de usuario de la lógica?

^{En primer lugar, el ejemplo que proporcionó no es increíblemente ineficiente; es solo un poco ineficiente; Su ineficiencia está por debajo del nivel perceptible. Pero, en cualquier caso, sigamos con la pregunta.}

De la forma en que lo entiendo, cuando hablamos de separación de UI y Lógica , nos referimos a evitar el acoplamiento cercano .

El acoplamiento cercano se refiere a la situación en la que la IU conoce (e invoca) la lógica, y la lógica conoce (e invoca) la IU. Para evitar el acoplamiento estrecho, no es necesario recurrir a abolir el acoplamiento por completo. (Eso es a lo que parece estar apuntando al demoler la interfaz entre ellos a una interfaz de cadena de mínimo común denominador). Todo lo que hay que hacer es emplear un acoplamiento suelto .

El acoplamiento flojo significa que A conoce a B, pero B no sabe a A. En otras palabras, las dos partes involucradas juegan roles distintos de cliente y servidor , donde el cliente conoce al servidor, pero el servidor no conoce al cliente.

En el caso de la interfaz de usuario y la lógica, la mejor manera de organizar esto en mi opinión es ver la lógica como un servidor y la interfaz de usuario como un cliente. Por lo tanto, la interfaz de usuario está construida para la lógica, tiene conocimiento de la lógica e invoca la lógica, mientras que la lógica no sabe nada sobre la interfaz de usuario y simplemente responde a las solicitudes que recibe. (Y estas solicitudes provienen de la interfaz de usuario, pero la lógica no lo sabe).

Para ponerlo en términos más prácticos, en ninguna parte de los archivos de código fuente de la lógica debería encontrar ninguna declaración de inclusión / importación / uso que se refiera a archivos de la interfaz de usuario, mientras que los archivos de código fuente de la interfaz de usuario estarán llenos de inclusión / importación / uso declaraciones que se refieren a archivos lógicos.

Entonces, para volver a su caso, no hay absolutamente nada de malo en el hecho de que el código de UI que llena el cuadro combinado sabe sobre la clase de hamburguesas. Habría un problema si la clase de hamburguesas supiera algo sobre cuadros combinados.

Por cierto, este diseño permite otra cosa que debe esperar de dicho sistema: debería ser posible conectar tantas IU diferentes como desee a la lógica, y todo debería funcionar.

Debe separar cada pieza del Modelo, Vista y Controlador, pero no hay ninguna razón por la que no pueda (por ejemplo) pasar objetos Modelo entre el Controlador y la Vista.

Entonces, en su caso, los Hamburgerobjetos serían parte del Modelo. Luego, utiliza su controlador para obtener la lista de correos electrónicos necesarios Hamburgery pasar esos objetos a la vista (el cuadro combinado) para que se muestren. Cuando su usuario ha seleccionado qué hamburguesa, puede volver a pasar el Hamburgerobjeto al controlador nuevamente para su procesamiento.

El punto es que aún puede probar la unidad de la Hamburgerlógica de "búsqueda " y la lógica de "proceso Hamburger" por separado de la visualización real de hamburguesas.