CSC/ECE 517 Fall 2013/ch1 1w29 rkld

Convention over configuration

Convention over configuration is a software engineering paradigm which aims at reducing the developers efforts by helping him take lesser decisions while still allowing flexibility.

The idea of convention over configuration is that rather than having to configure several or may be even one large configuration file, one must use conventions to determine how code should work without configuration. Convention over configuration (also known as coding by convention) simply requires to developer to adhere to the conventions specified by the underlying framework . If these are followed in the correct and appropriate manner, the framework interprets the code and delivers output as one would expect from a well defined configuration file.

Motivation

Many frameworks generally require programmers to use configuration files in order to configure and set up the framework. Configuration files essentially are used to provide mapping between the classes and the resources. Thus adding more classes and resources to the application simply leads to an ever growing configuration file. Thus it gets difficult to maintain these configuration files as more code gets added in the application.

<hibernate-mapping>
<class name= “Post” table=“posts”>
	<id name=“ID” column= “id” type=“integer”>
		<generator class=“assigned”></generator>
	</id>
	<property name=“category” column=“category” type=“string” />
</class>
</hibernate-mapping>

CREATE TABLE posts (
	id INTEGER(10) NOT NULL,
	category VARCHAR(2),
	PRIMARY KEY(id)
);

Thus hibernate uses the configuration files (Fig 1) and maps the objects to the corresponding database. Thus if we create an instance of the Post class and provide it with an ID and category, then simply calling the getId() function using that instance will perform a lookup in the database in the ID column and retrieve the relevant record. The Hibernate file shown above is an XML file. It becomes difficult to maintain these files as the complexity of the application code grows leading to errors in the configuration files which may not be detected at compile time but rather only at run-time. Errors like ClassNotFoundException are typical examples of this situation.

Thus a naming convention that is followed is 1. Database table names are pluralized form of the corresponding class name 2. Columns of the database should have the same name as that of the corresponding fields in the class to which they map to.

Developers generally follow these naming conventions while writing code. Thus the convention over configuration paradigm rewards developers by not having to configure any files by aiming at building and integrating it directly into the framework. Thus as long as the developer adheres to the standard naming convention, he need not write any configuration files. The framework will automatically (sometimes termed as automagically) query the database and find the corresponding table and the corresponding column in the table depending on the method and class used to invoke it. Thus convention over configuration reduces the amount of configuration by using a set of naming conventions that developers should strictly follow.

Benefits

Once developers learn the basic conventions followed by the system, the overall speed with which they will develop the system is increased. They don't need to worry about setting up configurations to get the system to behave as expected. Simple naming paradigms take care of basic routing, associations and application resource usage. Developers can easily grasp and understand how the modules of an existing system are set up. Making modifications to such modules developed by the team becomes a very fast and clear-cut process. Since the code follows the same basic sets of rules when it comes to naming, the design of the different modules is very straight lined, consistent and easy to understand. If the naming is done well and adhering to the established conventions, the possibility of manual error when making changes to an existing system is reduced. Uninformed changes to configuration files without a proper understanding of their usage can cause an entire system to halt and throw up errors. The system understands some things inherently and we don't need to explicitly guide it or tell it to take specific actions for different cases.

Usage in Ruby on Rails

Ruby on Rails promotes the idea of convention over configuration. Rendering by default is one example where this paradigm is used in Rails. By default Rails automagically renders views which have names which correspond to valid routes that may have been defined in routes.rb file.

Consider the code in the UsersController class

class UsersController  < ApplicationController
end

Also consider the following present in the routes.rb file

resources :users

And lets say there is a view file in app/views/users/index.html.erb

<h1> Users should be here soon ! </h1>

Now when the application starts and when you navigate to /users you should see “Users should be here soon !” on the page. Lets say we add an index action to our UsersController

class UsersController  < ApplicationController
	def index
		@users=User.all
	end
end

Here at the end of the index action we do not render anything. Thus since Rails follows the convention over configuration principle, it will automatically look for action_name.html.erb template in the controllers view path and render it. Hence it simply renders app/views/users/index.html.erb file.