Create high quality Web applications with rails

More and more companies are starting to choose rails as a framework for Web applications. Rails used to be primarily a choice for light companies, but today some "heavy" companies (such as insurance, finance and other industries) are starting to take rails into account within their internal applications and even outside applications. The client I recently served was a large foreign insurer, and the company chose rails to create their insurance sales website.

The reason for choosing rails is because it is built quickly because it is a DSL for web development. But is the rails chosen to represent efficient development? is a Web application created on rails necessarily of high quality? The answer is in the negative. From a few rails projects I've been involved in, the quality is uneven and the speed of development is Sheroyun. The inefficiency of the development is often due to the low quality of the application itself and the poor design.

In this article, I'll discuss several factors that affect the quality of Web applications. At the same time, we can learn about rails ' efforts to create high-quality Web applications, the implications of its various designs, and the implications and trends of the rails 3 improvements.

Mvc

We all know that rails is a web framework for MVC architecture patterns, and that the responsibilities of the MVC sections are clear. But the question is, do we really follow the MVC architecture pattern and do a clear separation of the responsibilities of each part? Do you follow the principle of a single responsibility?

In most code, this chaotic state exists between model and controller: Controller takes on too many responsibilities that should be assumed by model. One of the more typical examples is the inline (multiple) object form. For example, there is a one-to-many relationship between album and photo, and we want to create a album that contains multiple photo. Before Rails 2.3, we might write similar code:

AlbumsController
　 def　create
　　 album　=　Album.new　params[:album]
　　 album.photos　<<　Photo.new　params[:album][:photo]
　　 ...

If it is a form that involves more than one type of object, the code here can be more complex. But in Albumscontroller, what we really want to care about is the creation of album, not photo or other associated objects. And from the album Point of view, the creation process photo and other attributes no difference, should be treated in a consistent manner.

After Rails 2.3, we can do this very simply. To make such a statement inside the album:

class　Album　<　ActiveRecord::Base
　 ...
　 accepts_nested_attributes_for　:photos
end　

The code in controller can then be simplified to:

AlbumsController
　 def　create
　　 album　=　Album.new　params[:album]
　　 ...

From this example, you can see the effort and progress that rails has made in advancing the responsibilities between the three parts of MVC. Many people may say that our code does not have such a problem. But the responsibilities between the three parts of MVC begin to blur, often after the business logic becomes complicated. We should always look at our code and do the real job of being single.