Ви, напевно, часто чули про те, наскільки Ruby on Rails підвищує продуктивність і якість праці веб-програміста. Чесно кажучи, щоб повністю зрозуміти через що весь цей галас потрібно прочитати «Agile Web Development with Rails». Однак, в невеликій серії статей я все таки спробую дати загальне уявлення про те, що ж таке ці «рейки» і чим вони такі хороші.
Дуже коротка історія Ruby і RoR
Мені був потрібен «скриптова» мову, який був би потужніший, ніж Perl і більш об'єктно-орієнтованого, ніж Python. Тому я вирішив створити свою власну мову програмування.
З інтерв'ю для O'Reilly LinuxDevCenter
Фото з його офіційного блогу
Але це все були голі і нудні факти.
Коротко про галас і переваги
Якщо ви будете шукати інформацію про RoR, то натрапите на гучні заяви про те, що за допомогою цього фреймворка можна розробляти веб-додатки в 10 разів швидше, ніж на Java (з її фреймворками, зрозуміло) і т.п. Так от не вірте всьому цьому. Спочатку спробуйте самі, а потім вам вже не треба буде нічого говорити. Ви і так зрозумієте, що це дійсно правда.
Так чому ж такі хороші ці рейки? Найголовніше, на мою думку, це те, що фреймворк народжений не в штучних умовах, а «виламаний» з працюючого і приносить прибуток програмного продукту. Таким чином, ще до перших згадок, він пройшов обкатку в реальних умовах, з реальними користувачами і ризиками. Якщо ж дивитися на архітектурно-технічні аспекти, то
- по-перше, архітектура MVC дозволяє легко відокремити рівні даних, подання та бізнес логіки друг від друга;
- по-друге, RoR строго дотримується принципу DRY (Do not Repeat Yourself - не повторювати), що дозволяє писати гнучкі і легкосопровождаемие додатки;
- по-третє, Rails дозволяє зосередитися на завданні, а не на винахід колеса. Якщо вам потрібно перевірити заповнення чи поле name, ви просто напишіть validates_presence_of: name і перейдете до реалізації більш важливих речей (або підете пити чай);
- і нарешті, це фреймворк від практикуючих веб-програмістів практикуючим веб-програмістам, а не плід хворої свідомості - схиблених на теорії - «розробників», маркетингова заглушка або ж курсова робота з інформатики.
Рівень даних (Model) - ActiveRecord
ActiveRecord це реалізація ORM, що поставляється з Rails. Але що ж таке ORM? ORM (Object-Relational Mapping) - це техніка уявлення бази даних за допомогою об'єктів. Тобто клас представляє таблицю, об'єкт рядок, а його поля, відповідно, колонки. Оскільки більшості читачів знаком «C-like» синтаксис, наведу приклад на Java.
Візьмемо деяку таблицю books:
id int (10)
name varchar (100)
Ця таблицю можна уявити, як клас Book:
public class Book public int id;
public String name;
Тобто Book thinkinginjava = new Book (1); поверне нам рядок в таблиці books з id = 1.
ActiveRecord пропонує нам дуже багату реалізацію ORM, яка сама будує ієрархію класів, грунтуючись на структурі таблиці. До того ж, тут (як, втім, і всюди в RoR) підтримується принцип «угоди замість конфігурацій». Але текст текстом, а код скаже все сам за себе. Якщо взяти вищенаведену таблицю, то нам потрібно всього-лише запустити скрипт генерації моделі:
ruby script / generate model Book
І вуаля! В папці / app / models / з'явився файл book.rb, відкривши який ми побачимо приблизно наступний код:
class Book
Отже, що ж сталося? У нас з'явилася готова для роботи модель таблиці books. При ініціалізації Rails на увазі, що назва таблиці ця назва класу в множині, де слова розділені нижнім підкресленням. Тобто таблиці orders відповідає клас Order, line_items - LineItem, people - Person і т. д. Таким чином ми вже зараз можемо його використовувати:
defensivedesign = Book .new
defensivedesign. name = "Defensive Design for the Web"
defensivedesign. save
Як ми бачимо, за замовчуванням реалізовані атрибути класу, які відповідають колонкам в таблиці і методи CRUD (Create, Retreive, Update, Delete). Я не буду описувати тут ці методи, щоб не перетворювати цю статтю на якусь подобу мануала. Їх багато і вони дуже зручні.
Отже, за допомогою деякої «магії» за нас було зроблено величезну кількість рутинної роботи. Але, багато хто може подумати, що за межі цієї магії вилізти ніяк не можна. Це не так, тому що все «угоди» можуть бути легко проігноровані. Наприклад, якщо у вас вже є готова база даних, яку міняти ніяк не можна і таблиця для книг в ній називається knigi, то вам всього лише потрібно вказати на це:
class Book
end
Теж саме і з іншими речами, такими як, наприклад, первинні ключі. За замовчуванням, RoR має на увазі, що поле з первинним ключем називається id (що, до речі, дуже логічно), однак ви можете це виправити, написавши set_primary_key "kitob_cifra".
Одне з небагатьох місць, де потрібні налаштування це файл /config/database.yml, в якому ви вказуєте тип і назву бази. Варто зауважити, що при розробці рекомендується використовувати три однакові бази даних для трьох станів системи: production, development і test. Як видно з назв, production це база для стабільних версій системи, development - для розробки, а test призначається для автоматичних тестів.
Приклад файлу database.yml:
development:
adapter. mysql
database. books_development
username. root
password. password
host. localhost
test:
adapter. mysql
database. books_test
password. password
host. localhost
production:
adapter. mysql
database. books_production
password. password
host. localhost
На сьогоднішній день, Ruby on Rails підтримує такі СУБД, як MySQL, DB2, PostgreSQL, Oracle, SQLite, MS SQL Server.
Це далеко не все, що відноситься до ActiveRecord і я не сказав про зв'язки між таблицями, транзакції, аггрегации, зворотні виклики і багато іншого. Це просто не входить в формат даної статті. Зауважу тільки, що практично все в RoR реалізується чудово просто. Вам потрібно представити таблицю у вигляді дерева об'єктів, відсортованого по полю name? Немає нічого простіше!
class Category
end
Отже, ми побачили, що термін дії даних RoR реалізований в простому і, в той же час, дуже потужний інструмент - ActiveRecord, який бере на себе переважна більшість рутинних операцій і дозволяє зосередитися на самій задачі. Наступного разу я розповім про рівень бізнес логіки «на рейках», тобто про контролерах.