Convención sobre configuración

format_list_bulleted Contenido keyboard_arrow_down
ImprimirCitar

Convención sobre configuración (también conocido como codificación por convención) es un paradigma de diseño de software utilizado por los marcos de trabajo que busca reducir la cantidad de decisiones que un desarrollador debe tomar sin perder necesariamente flexibilidad y el principio de no repetirse (DRY).

El concepto fue introducido por David Heinemeier Hansson para describir la filosofía del framework web Ruby on Rails, pero está relacionado con ideas anteriores como el concepto de "valores predeterminados razonables" y el principio del mínimo asombro en el diseño de interfaces de usuario.La frase significa básicamente que un desarrollador solo necesita especificar aspectos no convencionales de la aplicación. Por ejemplo, si hay una clase "Ventas" en el modelo, la tabla correspondiente en la base de datos se llama "ventas" por defecto. Solo si se desvía de esta convención, como en el caso de la tabla "ventas de productos", es necesario escribir código para estos nombres.Cuando la convención implementada por la herramienta coincide con el comportamiento deseado, esta se comporta como se espera sin necesidad de escribir archivos de configuración. Solo cuando el comportamiento deseado se desvía de la convención implementada se requiere una configuración explícita.El uso de la frase en Ruby on Rails se centra particularmente en su archivo de proyecto predeterminado y la estructura de directorios, que evita que los desarrolladores tengan que escribir archivos de configuración XML para especificar qué módulos debe cargar el framework, algo que era común en muchos frameworks anteriores.

Desventajas

Las desventajas del enfoque de convención sobre configuración pueden surgir debido a conflictos con otros principios de diseño de software, como el principio de "lo explícito es mejor que lo implícito" de Zen of Python. Un marco de software basado en convención sobre configuración a menudo implica un lenguaje específico del dominio con un conjunto limitado de construcciones o una inversión de control en la que el desarrollador solo puede afectar el comportamiento mediante un conjunto limitado de ganchos. Ambos factores pueden dificultar la implementación de comportamientos que no se expresan fácilmente mediante las convenciones proporcionadas, en comparación con una biblioteca de software que no intenta reducir la cantidad de decisiones que los desarrolladores deben tomar ni requiere inversión de control.Otros métodos para reducir la cantidad de decisiones que debe tomar un desarrollador incluyen lenguajes de programación y bibliotecas de configuración con una arquitectura multicapa.

Motivación

Algunos frameworks necesitan varios archivos de configuración, cada uno con numerosas opciones. Estos proporcionan información específica de cada proyecto, desde URL hasta asignaciones entre clases y tablas de bases de datos. Muchos archivos de configuración con muchos parámetros suelen ser difíciles de mantener.Por ejemplo, las primeras versiones del mapeador de persistencia de Java, Hibernate, mapeaban las entidades y sus campos a la base de datos describiendo estas relaciones en archivos XML. La mayor parte de esta información podría haberse revelado mediante la asignación convencional de los nombres de clase a las tablas de la base de datos con el mismo nombre y los campos a sus columnas, respectivamente. Las versiones posteriores prescindieron del archivo de configuración XML y, en su lugar, emplearon estas mismas convenciones; las desviaciones se pueden indicar mediante el uso de anotaciones de Java (véase la especificación de JavaBeans, cuyo enlace se encuentra más abajo).

Usage

La herramienta de software Maven autogenerado esta estructura de directorios para un proyecto Java.
Muchos marcos de trabajo modernos utilizan un enfoque de convención sobre configuración.

Sin embargo, el concepto es más antiguo, ya que se remonta al concepto de valor predeterminado, y se puede encontrar más recientemente en las raíces de las bibliotecas de Java. Por ejemplo, la especificación JavaBeans se basa en gran medida en él. Para citar la especificación JavaBeans 1.01:

"Como regla general no queremos inventar una enorme java.beans.todo clase que la gente tiene que heredar. En su lugar, nos gustaría que los JavaBeans plazos de ejecución para proporcionar comportamiento predeterminado para los objetos 'normales', pero para permitir que los objetos anulen una determinada pieza de comportamiento predeterminado heredando de algún java específico.beans.something interface."

Véase también

  • Comparación de marcos web
  • Convención sobre el Código
  • Markedness
  • Desarrollo rápido de las aplicaciones

Referencias

  1. ^ Doyle, Kerry (11 de noviembre de 2021). "Programación en Ruby: Una mirada crítica a los pros y contras". Buscar App Architecture. Retrieved 17 de diciembre 2021.
  2. ^ Sol (24 de julio de 1997). JavaBeans specification Archived 6 April 2012 at the Wayback Machine, section 1.4.
  • Bächle, Michael; Kirchberg, Paul (2007). "Ruby on Rails". IEEE Software. 24 (6): 105–108. doi:10.1109/MS.2007.176. S2CID 9731264.
  • Miller, Jeremy (febrero de 2009). "Design for Convention Over Configuration". MSDN MagazineVol. 24, no. 2. Retrieved 9 de marzo 2022.
  • Chen, Nicholas (29 de noviembre de 2006). "Convención sobre configuración". Archivado desde el original el 25 de agosto de 2021.
  • Convención sobre configuración en la máquina Wayback (arquivado 2021-08-25)
Más resultados...
Tamaño del texto:
undoredo
format_boldformat_italicformat_underlinedstrikethrough_ssuperscriptsubscriptlink
save