Каковы преимущества использования STI против категории? - PullRequest
2 голосов
/ 03 ноября 2011

Это происходит из мира Rails, но это довольно общий вопрос о наследовании одной таблицы.Единственная причина, по которой я спрашиваю, состоит в том, что люди продолжают давить на меня ИППП, когда для этого нет явной причины.Может быть, я что-то упустил?Пожалуйста, рассмотрите эти два сценария для отображения и хранения содержимого страницы для различных страниц на сайте:

Сценарий 1

class ContentItem < ActiveRecord::Base
  belongs_to category
end

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

Сценарий 2

class ContentItem < ActiveRecord::Base

end

class FaqItem < ContentItem
end

class NewsItem < ContentItem
end

Здесь нет необходимости в категории, но если вы когда-либоМне нужно добавить еще один тип ContentItem, вам нужно создать другую модель, другую и т. д.

Моя проблема со сценарием № 2 заключается в том, что FaqItem & NewsItems точно такие же.Они никогда не будут разными.Единственное отличие состоит в том, что они могут быть изменены разными людьми (администратор сайта или пиарщик новостей).

Итак, хотя оба подхода хороши, зачем выбирать один сценарий из другого в этом конкретном случае?

Ответы [ 3 ]

2 голосов
/ 03 ноября 2011

Если есть только несколько категорий или типов, и много кода совместно используется, очень легко разместить его в одном классе. Но как только список увеличится, ваш код будет разбросан с помощью case операторов или if -деревьев, и вот где наследование пригодится.

Например:

def title
  case category_id
    when 'FaqItem'
      do_1_thing
    when 'NewsItem'
      do_another_thing
  end
end

в отличие от

class FaqItem < ContentItem
  def title
    do_1_thing
  end
end  

class NewsItem < ContentItem
  def title
    do_another_thing
  end
end  

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

Тем не менее: вопрос о том, как скоро вы перейдете на использование STI, зависит от сложности вашего кода.

1 голос
/ 03 ноября 2011

Мне нравится использовать STI в Rails, когда (а) вам нужно определенное поведение в одном или нескольких подклассах и (б) вы собираетесь выполнять поиск родительского класса и подкласса в разных частях приложения.

В приведенном вами примере, возможно, все ContentItems будут иметь атрибут "title". Но, возможно, FaqItem также нуждается в атрибуте «answer», и, возможно, этот атрибут требуется посредством проверки.

Также, возможно, вашему приложению понадобится страница часто задаваемых вопросов, содержащая только часто задаваемые вопросы (FaqItem.all). Но, возможно, для этого также потребуется полная страница индекса со всеми элементами контента (или функцией поиска).

Подобные вещи пригодятся STI.

(также не забудьте создать индекс для столбца вашего типа)

1 голос
/ 03 ноября 2011

Я не знаком с термином «Наследование отдельных таблиц», но он выглядит как экземпляр стандартного аргумента о создании подклассов в сравнении с кодами типов.Люди спорят об этом , потому что оба варианта могут быть правильным выбором, в зависимости от обстоятельств.Мой прагматичный совет: выбирайте ту тактику, которая приводит к меньшему дублированию кода, учитывая более широкий контекст.Рассмотрите не только те категории, которые есть у вас сейчас, но и возможность добавления новых категорий в будущем.

...