1

我最近刚刚继承了一个 Rails 应用程序，并且正在讨论向前推进的架构决策。这里有一些背景......感谢您的反馈。

目前有 16 种不同的广告类型，它们都具有一组相同的属性，一些具有一个或两个附加属性，还有一些具有三个或四个属性。

目前，每种广告类型都有一个单独的模型和带有相应列的表格，以及一个单独的控制器和 CMS 中的视图，也用于基本的 CRUD。CMS 利用了inherited_resources，从而限制了一些重复。

我写出了属性集——大约有 20 个，涵盖了所有广告类型。某些广告类型具有关联 - 几个 has_many 关联，其中外键存储在关联表中，还有一些属于_to。

广告没有实际行为。特定的广告类型只是简单地显示在各个页面上，所以只要我能确定是否有特定类型的广告，我们就可以了。

我正在讨论转向单个模型、表和控制器，但希望从 stackoverflow 社区获得尽可能多的输入，以了解这是否 1）非常适合问题 2）任何性能问题 3）任何潜力我没有想到的编程瓶颈。到目前为止，这是我的想法......

假设路线 /:location/:ad_type/new（例如 /homepage/ad_type_1/new）：

ad_controller 将创建 @ad 并将 ad_type 设置为 params[:location] + params[:ad_type] 并渲染新视图，该视图将包含一系列条件，用于显示给定 ad_type 的适当部分。提交将触发创建操作，使用为广告类型定义的预期属性创建广告，在这种情况下，其中之一是 ad_type = homepage_ad_type_1。

我没有过多考虑检索数据，但假设 ad_type 列设置正确，我应该能够创建一个基于 ad_type 列提取记录的“of_type”范围。不确定我是否在那里遗漏了什么。

验证将根据 ad_type 值而有所不同。

我不完全确定在任何给定时间会存在多少广告，但我觉得这可以在以后解决。通过将一些陈旧的行移到 ad_archives 表或类似的表中。

感谢您的想法。谢谢。

4

1 回答 1

1

我可能会为此使用单表模型，但如果使用多个控制器/视图有意义，您不必将自己限制为单个控制器，并且您仍然可以根据广告类型查询广告而不使用条件。例子：

create_table :people do |t|
  t.string first_name
  t.string last_name
  # some other properties...
  t.string type
end

class Student < Person
end

class Teacher < Person
end

Person.all # shows all students and teachers
Teacher.all # shows all teachers

所以很容易制作一个 Teachers 控制器和一个 Students 控制器，以及一个 People 控制器。

于 2010-12-15T16:31:58.510 回答