CODEWITHSUNDEEP
ruby-on-railsrubyperformance
Arivarasan L
Arivarasan L

Reputation: 9958

rails coding conventions to improve performance

In my current project, i notice few thing,

  1. Maximum part of the business logic are moved to helper.
  2. Included all helper files in a module under lib directory and included that module in application controller.
  3. In many methods, no argument passed, instead they used the instance variable(create instance variable in calling method and use that instance variable in the called method).
  4. Each action will call a helper method to execute business logic and that method will call some other helper methods.
  5. All method are written as public, No protected and private method.
  6. Models are used only for validation.

are those points follows good coding conventions? if not, can you suggest me the best coding standard to improve performance?

Upvotes: 2

Views: 308

Answers (2)

mdesantis
mdesantis

Reputation: 8517

Performance is not related to your arguments; they are about project organization.

Maximum part of the business logic are moved to helper

This shouldn't happen, you should move the business (aka models) logic inside the models. Rails doesn't force you doing it, so keeping the logic organization is up to developers.

Models are used only for validation

This is a consequence of putting the business (aka models) logic outside the models. You should move it from the controllers/helpers to the models. Again, Rails doesn't force you to do that, so it's up to developers to do it.

Included all helper files in a module under lib directory and included that module in application controller.

In many methods, no argument passed, instead they used the instance variable(create instance variable in calling method and use that instance variable in the called method).

Each action will call a helper method to execute business logic and that method will call some other helper methods.

All method are written as public, No protected and private method.

I think that these points are (some more, some less) related to the Rails Helper design. One flaw of Rails is the Helper design: they go against the OO pattern and usually end up by being a bunch of unorganized functions, à la PHP.

For this reason some people use Decorators. Decorators "add an OO layer of presentation logic" (from Draper), allowing to organize better the view related methods.

If you want to examine the argument, I suggest you the following links:

Upvotes: 2

pdu
pdu

Reputation: 10413

First, convention has nothing to do per se with performance.

Maximum part of the business logic are moved to helper.

I would say this is very bad. One of the popular idioms is "fat models, skinny controllers", which works most of the time. Put all the business logic you can in your models, where they belong. If you have really complicated views you want to simplify, use decorators (e.g the draper gem), and then separate business logic (model) and view logic (decorators) into their according locations.

Included all helper files in a module under lib directory and included that module in application controller.

Okay I think. As long as you have one place to maintain that chain, it feels okay. If it leads to misunderstandings/misusings/hacking around, then: not okay.

In many methods, no argument passed, instead they used the instance variable

If you're talking about methods in your model: this is good, since the method is targeted at the scope of your instance, and not of your class.

Each action will call a helper method to execute business logic and that method will call some other helper methods.

Sounds strange. The controller is responsible for preparing your data used in the view. If you are preparing specific data in your helpers to assign them to your view for usage, consider putting these into a decorator (as mentioned above). But calling a helper in almost every action sounds like something is done the wrong way.

All method are written as public, No protected and private method.

Non-public methods should not be public. Take a look at helper_method and hide_action from ActionController.

Models are used only for validation.

Wrong. Models contain the business logic, as mentioned above. What about modifying things in the console? Would you want to update all logical related data by hand, then? Do you do this "by hand" in your controller right now (which it seems like) ? What about when you introduce an API, do you copy-paste the code in there to not miss some logic? And what when the logic changes, are you really sure all required endpoints manually and independently handling that logic are also updated?

There's a reason models have relations, callbacks and instance methods. Use them!

Upvotes: 3

Related Questions