Convention over configuration
Convention over configuration (also known as coding by convention) is a software design paradigm which seeks to decrease the number of decisions that developers need to make, gaining simplicity, and not necessarily losing flexibility.
The phrase essentially means a developer only needs to specify unconventional aspects of the application. For example, if there is a class Sales in the model, the corresponding table in the database is called "sales" by default. It is only if one deviates from this convention, such as calling the table "product sales", that one needs to write code regarding these names.
When the convention implemented by the tool matches the desired behavior, it behaves as expected without having to write configuration files. Only when the desired behavior deviates from the implemented convention is explicit configuration required.
Motivation
Some frameworks need multiple configuration files, each with many settings. These provide information specific to each project, ranging from URLs to mappings between classes and database tables. A large number of configuration files with lots of parameters is often difficult to maintain.
For example, early versions of the Java persistence mapper Hibernate mapped entities and their fields to the database by describing these relationships in XML files. Most of this information could have been revealed by conventionally mapping class names to the identically named database tables and the fields to their columns, respectively. Later versions did away with the XML configuration file and instead employed these very conventions, deviations from which can be indicated through the use of Java annotations (see JavaBeans specification, linked below).
Usage
Many modern frameworks use a convention over configuration approach.
The concept is older, however, dating back to the concept of a default, and can be spotted more recently in the roots of Java libraries. For example, the JavaBeans specification relies on it heavily. To quote the JavaBeans specification 1.01:[1]
"As a general rule we don't want to invent an enormous java.beans.everything class that people have to inherit from. Instead we'd like the JavaBeans runtimes to provide default behaviour for 'normal' objects, but to allow objects to override a given piece of default behaviour by inheriting from some specific java.beans.something interface."
See also
- Comparison of web application frameworks
- Frameworks that use the paradigm:
- ColdBox Platform runs on Railo
- Ruby on Rails
- Lift (web framework)
- CakePHP
- Apache Maven
- Grails
- Symfony
- Appcelerator's Titanium Alloy
- Yii
- Laravel
- Crosslight
- Durandal (JavaScript SPA Framework)
- Ember.js
- Java Platform, Enterprise Edition
- ASP.NET MVC
- Spring Framework
- Contao
- Sails (web framework)
- Meteor (web framework)
- Roxy rest-API
- Play Framework
References
- ↑ Sun (24 July 1997). JavaBeans specification, section 1.4.
- Bachle, M., & Kirchberg, P. (2007). "Ruby on rails". Software, IEEE, 24(6), 105-108. DOI 10.1109/BCI.2009.31.
- Miller, J. (2009). "Design For Convention Over Configuration". Microsoft, Retrieved 18 April 2010.
- Chen, Nicholas (2006). "Convention over configuration".
