Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Five common misunderstandings in Rails development

2025-01-18 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

Share

Shulou(Shulou.com)06/03 Report--

This article mainly introduces "5 common Rails development misunderstandings". In daily operation, I believe many people have doubts about 5 common Rails development misunderstandings. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the "5 common Rails development misunderstandings". Next, please follow the editor to study!

1. Migration without schema specification

The data model is the core of the application. Without the constraints of schema, your data will slowly get worse because of the bugs on the project code, until you can't trust any fields in the library. Here is a Concact Schema:

Create_table "contacts" do | t | t.integer "user_id" t.string "name" t.string "phone" t.string "email" end

What needs to be changed above? Usually a Contact must be attached to the User and will have a name attribute, which can be ensured using database constraints. You can add ": null = > false" so that even if there is bugs in the validation code, we can still ensure model consistency, because the database will not allow the model to save the data if the null constraint is violated.

Create_table "contacts" do | t | t.integer "user_id",: null = > false t.string "name",: null = > false t.string "phone" t.string "email" end

TIPS: use ": limit = > N" to specify the size of your string type fields. Strings defaults to 255characters, and the phone field should not need to be so long!

two。 Object oriented programming

They usually write MVC-oriented Ruby code in the project (separate the model from the controller in place). But it often takes developers 2-3 years to realize that "Rails is Ruby. I can create some simple objects and don't necessarily encapsulate them in the way Rails suggests."

TIPS: use facade (facade pattern) for the third-party service you invoke. By providing mock facade in the test, you don't have to actually call these third-party services in your test set.

3. Connect HTML in helpers

If you are creating a helper, congratulations, at least it means you are trying to make your view layer cleaner. But developers often don't know some common ways to create tags using helpers, which leads to poor string concatenation or poor interpolation.

Str = "" str + = link_to ("# {vehicle.title.upcase} Sale", show_all_styles_path (vehicle.id, vehicle.url_title)) str + = "" str.html_safe

See, it's pretty bad, and it's easy to lead to XSS security vulnerabilities! Let content_tag save the code.

Content_tag: li,: class = > 'vehicle_list' do link_to ("# {vehicle.title.upcase} Sale", show_all_styles_path (vehicle.id, vehicle.url_title)) end

TIPS: start using blocks (code blocks) in helper now. When an embedded HTML is generated, the embedded blocks is more natural and appropriate.

4. Giant Queries (a large query, such as a query that loads a whole table) loads everything into memory

User.has_purchased (true) .each do | customer | customer.grant_role (: customer) end

Suppose you have an e-commerce site with other customers, assuming that each user object requires 500 bytes, and the above code consumes 500 megabytes of memory at runtime.

Here's a better way to do this:

User.has_purchased (true) .find_each do | customer | customer.grant_role (: customer) end

Find_each uses find_in_batches to fetch 1000 records at a time, which is very effective in reducing memory requirements.

TIPS: use update_all or raw SQL statements to perform large update operations. It may take some time to learn SQL, but the benefits are obvious: you will see an improvement in 100x performance.

5. Code review

I guess you will use GitHub, and I further guess that you will not go to pull requests (the application code merge operation on GitHub). If it takes you a day or two to build a new feature, go to a branch and send a pull request. The team will review your code and make suggestions for improvements or features that you haven't considered.

At this point, the study on the "five common misunderstandings in Rails development" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Development

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report