Model-View-Controller или как я понял что такое архитектурный паттерн MVC

Large mvc
Для того что бы повышать свои знания, что бы было удобно и легко разрабатывать приложение дальше мне пришлось немного отвлечься и прочитать немного литературы по поводу паттерна MVC.

Данный паттерн есть не только в языке Ruby on Rails, его используют везде. Я буду говорить как я поняло для себя что такое MVC, несмотря на то, что в интернете очень много статей которые противоречат друг другу... Поэтому я собираюсь конкретизировать именно к своему приложению все объяснение.

В начале был контроллер... хотя нет, сначала роутинг!

Ну на самом деле начинается все раньше чем в контроллере, как можете наблюдать на картинке выше сначала пользователь заходит на какую нибудь страницу сайта например:
http://birbrover.gq/posts/1
в рельсовом приложении есть специальный файл config/routes.rb вот как раз он принимает на себя запрос и понимает по заранее записанным в него параметрам, что данный url хочет от контроллера(в моем случае контроллер с названием PostsController)

Вот так будет выглядит простое правило для того что бы понимать что от нас хочет пользователь
get 'posts/:id' => 'posts#show'
но опять же данная запись не очень принята для сущностей со стандартными требованиями, такими как:
  • Создать новый элемент
  • Изменить существующий элемент
  • Показать существующий элемент
  • Удалить существующий элемент
Для этого пришлось бы написать длинный и некрасивый код:
get 'posts/new' => 'posts#new'
get 'posts/:id/edit' => 'posts#edit'
get 'posts/:id' => 'posts#show'
delete 'posts/:id' => 'posts#destroy'
и т.д. ведь это только страницы которые мы видим, а так еще есть скрытые маршруты роутера, которые идут в фоновом режиме.

В Rail`s есть более сокращенная реализация таких стандартных решений:
resources :posts
Да, вот так вот одной строкой мы заменили около 8 маршрутов =)

Ну теперь точно про контроллер.
Теперь когда запрос от пользователя по урл обработан роутером и направлен в нужный контроллер можем посмотреть как тут внутри все происходит.

Рассмотрим нам известный пример:
get 'posts/:id' => 'posts#show'
вот как выглядит метод в контроллере, на который ссылается роутинг

class PostsController < ApplicationController
  def show
  end
end
Да эта вся реализация которая нужна в контроллере, что бы вы могли увидеть свою вьюшку(страницу) если она у вас уже создана. Наверняка сейчас тот, кто не знает, что такое контроллер задается вопрос а зачем тогда он нужен, но на самом деле для более сложных страниц внутри этих методов пишется логика. Вы можете передать на страницу какие нибудь параметры, отловить из контроллером и исходя из этого выдать ту или иную страницу сайта, вы можете делать проверки полей в форме а так же обращаться через модель к базе данных и держать в себе данные после запросов.

V - значит Вьюшка.
Тут будет все очень просто - "вьюшка" - это просто ваша HTML страница, ваше отображение данных. В Rail`s по умолчанию выбран язык разметки ERB, я не буду на нем останавливаться, т.к. решил сразу использовать более удобный язык HAML.
поэтому вместо обычной HTML страницы show.html
<!DOCTYPE html>
<html>
<head>
    <title>Document</title>
</head>
<body>
    <h1>Hello World!</h1>
</body>
</html>
Мы создаем особенные HAML страницы show.html.haml
!!! 5
%html
  %head
    %title = "Document"
  %body
    %h1 = "Hello World!"
Как видите вместо 9 строк осталось всего 6, а когда у вас 900 строк будет? конечно HAML убыстряет процесс разработки и поддержки кода.

Вьюхи должны называться так же как и методы в контроллере, поэтому методы нужно пустыми, но создавать.

На случай если нам нужна работа с базой данных есть МОДЕЛЬ

Мне кажется тут больше и добавить то больше нечего, модель общается с базой данных, в моделе вы прописываете параметры той или иной сущности, например какие параметры у постов:
  • Название
  • Краткое описание
  • Тело поста
  • Фото
  • И т.д.
Указывая эти параметры при создании модели формируются файлы миграции, что такое миграция я расскажу в другом посту, но это такой файл который напрямую отдает команды базе данных по изменению таблиц, по добавлению данных и прочей работе.

Если вернуться к моделе, то тут можно указывать правила, что бы поле название было обязательным, что бы пароль был защищенным и прочие нюансы баз данных.

Итог!

Я понимаю, что пост затянулся и что многие не уловили мысль, но поверьте на слово, что это только первый раз так тяжело, если вы попробуйте работать по этому паттерну, то потом поймете все его преимущество и красоту, все модульное, легко заменяется и т.д. в общем имея начальные представления можно идти дальше.