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 leads to an ever growing configuration file. Over the period of time 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)
);

As seen above hibernate uses configuration files and maps the objects to the corresponding table in the 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.

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.

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 conventions as defined by the underlying framework, 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 conventions that developers should strictly follow.

Benefits

• Once developers learn the basic conventions followed by the framework, the overall speed with which they will develop the application is increased. They do not need to worry about setting up configurations to get the application 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.

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.

Another example of conventions followed by Rails is the naming of the model classes, controller classes and the views. The corresponding model class for the "UsersController class" will be named as "User" whereas the folder where all the view for the "UsersController" are stored will be name as the pluralized form of the model class. Hence all views related to this class will be found in app/views/users/... Again the database table related to the user model class will be named as the pluralized form of the model class and hence will be named as "users". However the names of the columns in the database table should be identical to that of the fields of the class.

Since Rails uses the Model-View-Controller (MVC) paradigm. Thus a developer will find himself looking at controllers and views and models for the applications database. Thus the Rails framework has set up rules to make things easy for the developers in order to reduce the need to set up heavy configuration files. Thus developers working on Rails should adhere to the conventions that Rails has to offer. These conventions when followed correctly will keep the code concise and simple and most important they allow for a smooth workflow and easy navigation through the application.

Major frameworks employing this paradigm

ASP.NET MVC

The .NET MVC framework mainly uses directory structure and naming conventions to enforce convention over configuration. It requires the developers to follow a set of rules for automatic routing and avoid configuration files for some default behaviors. Some of the rules are,

1. Controller class names need to be suffixed with the word “controller”<ref name="Controller">MVC Framework and Application Structure. Retrieved from http://msdn.microsoft.com/en-us/library/dd410120%28v=vs.100%29.aspx</ref>
2. Views should be placed in the folder “views/controllerName”<ref name="Controller"></ref>
3. Form fields should match the names used for Model properties for proper data binding <ref name="Data Binding">The Features and Foibles of ASP.NET MVC Model Binding. Retrieved from http://msdn.microsoft.com/en-us/magazine/hh781022.aspx</ref>
4. The default view for an action method should be named after that method. <ref name="Action Methods">Controllers and Action Methods in ASP.NET MVC Applications. Retrieved from http://msdn.microsoft.com/en-us/library/dd410269%28v=vs.100%29.aspx</ref>

Spring Web MVC

This framework relies on the naming conventions used in the application to set up handler mappings, view resolvers etc. It cuts down the amount of configuration that might be otherwise required for the set up. The paradigm support is mainly in the models, view and controller. Some of the conventions are, <ref name="SpringMVC">Convention over configuration. Retrieved from http://docs.spring.io/spring/docs/3.0.0.M3/reference/html/ch16s10.html</ref>

1. Controller class names are suffixed with "Controller" for automatic request URL mapping
2. The model has a ModelMap class which allows to make adding objects to be displayed in a view to stick to some existing naming conventions
3. View names (.jsp files) need to match the view requested in the request URL

Various other frameworks like Ember.js, Grails, Apache Maven also support the convention over configuration paradigm.

References

<references />