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

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

Basic principles of Rails

The Ruby on Rails framework is not a typical application development framework that you think. David Heinemeier Hansson, the founder of Rails, often calls the framework opinionated software, and he likes to break long-standing conventions. David makes very philosophical decisions and strictly follows them throughout the framework. The core ideas that spread throughout Rails are:

◆ seamless integration: Rails cleverly takes advantage of the Ruby language's * features. It extends Ruby, but it's hard to tell where the Ruby ends and where the Rails begins. You can also see a good integration between Active Record (the persistence engine of Rails) and the Model-View-Controller (MVC) framework. For example, you can write three lines of code, create a table, and then immediately generate a user interface for the model.

◆ conventions are better than configuration: to maintain good flexibility, the Java framework maintains a large number of common configuration files. Rails does not adopt this strategy. It uses the normal project directory structure and simple naming conventions for methods, classes, tables, and columns to infer which ones are configured in the Java application. As a result, Rails applications require only a small portion of the configuration code corresponding to Java applications, typically 1/10 or more.

◆ low repetition: don't repeat yourself (Don't Repeat Yourself,DRY) is a common term in the Rails community. The Rails Framework Committee abstracts repetitive tasks using an extension that usually looks like the Ruby language. As you saw in the third article in this series, Rails's metaprogramming strategy makes each line of code perform more tasks.

◆ instant feedback: with Rails, you will give instant feedback on most of the work you do. After you write a line of code and save it, your changes will be activated when the next Web page is loaded. After you update your database, the migration can show you the changes immediately.

Practical basis

The underlying ideas of Ruby on Rails are all based on practical experience. The Rails framework grows from practical experience in developing popular Basecamp project management applications.

Focus on a particular area

The argument against its claim of excessive productivity usually goes something like this: if you get a good hammer, it's hard to find another hammer that is twice as productive, let alone five to 10 times more productivity. because hammers have evolved for thousands of years. But people who compare Ruby on Rails to various general-purpose Java frameworks miss the point.

Productivity can be increased tenfold in some ways by fundamentally changing the nature of the tool. Professional manufacturers now use nail guns to drive a lot of nails in the time it takes to drive a nail into a nail with a hammer. Like a nail gun, Rails has a special purpose. It is a framework written specifically for a single domain: the new Web application that supports databases.

I guess half of the applications built today are database-enabled and Web-based applications. So Rails is a product that is specific to a certain area, but this area is large and important. Specializing in this field makes Rails have a great advantage and cause a great sensation. By focusing on projects in this area, Rails designers can choose shortcuts that other frameworks cannot or should not take. This specialization often loses flexibility for simplicity.

Web-based applications allow a similar set of optimizations. When you know that an application is Web-based, you know the general structure of the application and the major components that may be required. Because Rails focuses on Web-based applications, the following features have been enhanced in Rails:

◆ Model-View-Controller: Rails's MVC framework (called Action Pack) customizes Web-based access and implements a well-known design strategy called Model 2. The Rails version has optimized the integration between the controller and the view (which minimizes the configuration file) and automatically makes the controller instance variables available to the view.

◆ project directory structure: all Rails applications have the same project structure, with directories for storing application code, database configuration, common static files, and scripts for managing Web servers and conducting Web-based functional tests.

◆ architecture: the Rails framework simplifies architecture by providing out-of-the-box scripts for generating application components that meet common architectural goals, such as page-level and fragment-level caching; two-tier designs; and environments for testing, development, and production.

◆ tool: the Rails tool is dedicated to Web. Log support, breakpointer, profiler, and the testing framework are all pruned for Web-based applications and enabled for two-tier operations. But nail guns will never replace hammers, and we foolishly hope to replace them completely. Hammers can always do things that nail guns can't do. Rails will never be a tool for enterprise integration, object-relational mapping, or full-stack Web services. What you can expect from Rails is that it is a specialized tool that satisfies the domain it targets.

Developer practice

As you begin to delve deeper through the surface, you begin to understand that Rails developer practices are so completely different. A fast feedback cycle, each interaction control, and convention over configuration all enhance developer practices in areas that are not commonly used in the Java framework.

Feedback period

One of the most important factors affecting developer productivity is the overall feedback cycle. The feedback cycle is the time it takes from changing the code to seeing the results of executing the application on the screen. In Rails, you can get immediate feedback when coding. This feature is significant when you make changes to your Ruby code. You can load a browser page immediately to see the results of the changes. Because there is no need to compile or deploy during development, I tend to make only minor changes to programming before reloading the browser or executing test cases. Almost every Java developer who starts using Rails codes in smaller blocks.

You may think that a quick feedback cycle that is practice-friendly to developers does not support a production environment. After all, reloading classes frequently can get a quick feedback cycle, but it slows production applications. But Rails avoids this problem by providing different environments for deployment and development. In the development environment, classes are forced to be reloaded frequently at the expense of application performance, while the production environment reduces class reloading to a * limit, at the expense of the developer's quick feedback cycle. provide a fast experience for end users.

Interactivity

The interactive experience of Ruby also helps Rails. You might think that debugging a Rails application without a complete IDE would be a painful process. In fact, this is not the case. Rails provides two features that simplify debugging. One is breakpointer, which allows you to add the breakpoint keyword to the source code.

To understand how breakpointer works, you can create a simple Rails application, generate a controller, start the server, and start breakpointer. Make sure you have access to the breakpointer window because you will use it when Ruby encounters a breakpoint. When using Windows, the command sequence is as follows:

> rails sample > cd sample > ruby script/generate controller samples > start ruby script\ server > start ruby script\ breakpointer

If you are running in UNIX ®or Mac OS X, make sure the server starts in a separate process. Type or paste the following code into the app/controllers/samples_controller.rb file:

Class SamplesController

< ApplicationController def index breakpoint @session[:message] = "hi, mom" render_text "Showing index" end def show render_text @session[:message] end end 通过加载页面localhost:3000/samples和localhost:3000/samples/show来测试代码。当Rails执行到断点时，应用程序暂停。breakpointer窗口用具有控制器当前状态的环境打开一个Ruby解释器。然后可以执行Ruby命令来查询会话的状态、执行方法和查询变量： >

Puts @ session [: message]-> hi, mom

This closeness does not give you a complete debugger, but you do get features that the Java debugger does not give you, including access to a complete interpreter and ways to execute the application.

Convention is better than configuration

Convention over configuration also allows new Rails developers to get started immediately because the controller and model code is particularly concise. In retrospect, a Person object that has many properties and has an one-to-many relationship with a department (department) might look like this:

Class Person < Active Record::Base belongs_to: department end

No configuration is required because Rails deduces the name of the table (people), the object identifier and the name of the primary key (id), the name of the related table (departments), the name of the foreign key (department_id), and the name of the external class (department.rb) according to the naming convention. The code remains simple, lightweight, and very pleasing to the eye, whether for writing, reading, or maintenance. The purpose is direct and clear.

What can Java developers learn?

I don't recommend building a better Rails in the Java language here. Instead, Java developers should learn some lessons from the Rails framework and try to build or enhance the Java framework to accomplish the following tasks:

◆ allows hot deployment, which shortens the development feedback cycle or supports frameworks that allow hot deployment. This priority should be much higher on the Java side than it is now.

◆ uses less XML and more conventions. Convention and configuration is not that the well water does not interfere with the river water, because the convention can be used to specify explicit default values and the configuration can be used to override the convention. Using this approach like Rails, you can have the best of both worlds: concise code with less repetition without losing flexibility. To browse the Java class during debugging, merge more scripting languages, including BeanShell.

◆ chooses the right tool for the task. You don't have to resort to Hibernate just because you need persistence or Struts simply because you need Web applications. By incorporating the * features of other programming languages, you don't have to repeat Rails, but you can certainly improve the Java experience.

At this point, the study of "what are the basic principles of Rails" 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.