CSC/ECE 517 Fall 2012/ch2b 1w68 ss

Editing SaaS - 3.16. Finishing crud - Ruby

CRUD

CRUD operations are basic database operations of a persistent storage system that includes Create,Read,Update and Destroy. In rails Create, Read, Update and Destroy are supported by many methods provided by ActiveRecord, making it independent of any database. Since Rails follows MVC(Model-View-Controller) architecture, these three parts are responsible for making all these operations possible.

Update

Update is used to update an existing instance record of an application. Edit/Update pair is analogous to New/Create pair. As seen in the in New/Create functionality, the first action will retrieve the form and the second action will apply the changes and results of what the user passed into the form. The submit action redirects to the show action and shows the new modified item that was updated. For the update functionality,the Form should be available with the existing fields populated. Also,the form action uses PUT method instead of the POST method.

The code for Edit in the controller is as follows:

def edit
@movie = movie.find params[:id]
end

Here, the instance variable movie which is to be edited is replaced with the name of the movie it will be edited into.

Update looks similar to create action. The instance variable movie is first retrieved and then updated using update.attributes! where the parameters are passed in. The update.attributes! indicates that it is a destructive action. The code for Update in the controller is as follows:

def update
@movie = movie.find params[:id]
@movie.update_attributes!(params[:movie])
flash[:notice] = ""
redirect_to movie_path(@movie)
end

In the view, a form tag is used for the movie instance. By default, the method used will be POST but we are explicitly setting the method to PUT. Sample code is as follows:

form_tag movie_path(@movie), :method => :put do
label :movie, :title, 'Title'
text_field :movie, 'title'
submit_tag 'Update Movie Info'

Destroy

Destroy is an instance method on a particular item. The instance variable must be loaded up first, and then it can be destroyed.

def destroy
@movie=Movie.find(params[:id])
@movie.destroy
flash[:notice]="movie '#{@movie.title}'deleted."
redirect_to movies_path
end

As seen in the code example, the instance variable of the movie is first retrieved and then destroyed using "destroy". Also, it can be seen that when we do the Edit action we load up the instance variable and then do so again for the Update action. This is because the instance variable only persists for a certain request.

Fallacies, pitfalls and perspectives on SaaS-on-Rails

The MVC architectural pattern describes a way to structure our application and the responsibilities. The design also defines the way in which the three different components interact with each other.

1. A controller can send commands to its associated view to change the view's presentation of the model (e.g., by scrolling through a document). It can send commands to the model to update the model's state (e.g., editing a document).

2. A model notifies its associated views and controllers when there has been a change in its state. This notification allows the views to produce updated output, and the controllers to change the available set of commands. A passive implementation of MVC omits these notifications, because the application does not require them or the software platform does not support them.

3. A view requests from the model the information that it needs to generate an output representation.

Under this architectural pattern, the common pitfalls to be avoided are:

1. Fat Controllers:

Controller is the first place where we write code so we have to make sure that they should be as lean as possible. Fat Controllers are not recommended because business logic is enclosed in the controller and changes made are not reusable in other controllers. Also, its more difficult to port changes to other controllers, etc. when changes have to be made.

2. Fat views:

Its always recommended to not have the application or model logic in the view. Views, just like the controllers have to be as lean as possible. Some common mistakes in this regard can be:

1. Including "for loops" in the view

2. Placing the logic for sorting the list and so on..

Essentially views are meant to serve as a structure for the display of your model data. Therefore, the view is serving its purpose if the structure it creates for the display of a specific model can be adjusted based on the data contained in the model. Conditionally displaying elements in your view based on certain properties of the model it is meant to render is an acceptable practice.

If your view contained logic to modify the model data in any way, this would violate the separation of concerns that MVC is meant to establish.

Therefore, it is only recommended to have fat models in the application because the business logic changes will be easier to make and moreover the models become reusable in more than one controller and thus it is easier to unit test.

Designing for Service Oriented Architecture.

In software engineering, a service-oriented architecture (SOA) is a set of principles and methodologies for designing and developing software in the form of interoperable services. These services are well-defined business functionalities that are built as software components (discrete pieces of code and/or data structures) that can be reused for different purposes. SOA design principles are used during the phases of systems development and integration.

SOA generally provides a way for consumers of services, such as web-based applications, to be aware of available SOA-based services. For example, several disparate departments within a company may develop and deploy SOA services in different implementation languages; their respective clients will benefit from a well-defined interface to access them. XML is often used for interfacing with SOA services, though this is not required. JSON is also becoming increasingly common.

If the conventions mentioned in the previous section are followed, it will easily allow our application to integrate with Service Oriented Architecture. A well defined controller can be easily modified to make it amenable to Service Oriented Architecture (i.e. respond to SOA (JSON / XML) )

A simple example of the same can be seen below. Based on the client requirement, an appropriate response is generated.

def create
..
respond_to do |client_wants|
client_wants.html{ redirect_to movie_path(@movie) }
client_wants.xml{ render :xml => @movie.to_xml}
end
..
end

Summary

1. In rails Create, Read, Update and Destroy are supported by many methods provided by ActiveRecord, making it independent of any database. Since Rails follows MVC(Model-View-Controller) architecture, these three parts are responsible for making all these operations possible.

2. MVC Pattern encourages to include more code into the models, so that they can be reused across multiple controllers and views. This implies easier SOA Integration.

3. Rails encourages convention over configuration and follows many standard conventions. Following these avoids writing more code which indirectly leads to lesser number of bugs.