Question

我想知道是否有人尝试构建类似

的Rails项目

用户
- users.rb的
- users_controller.rb
- users_index.html.erb
- users_show.html.erb
帖子
- posts.rb
- posts_controller.rb
- posts_index.html.erb
- posts_show.html.erb

而不是Rails默认，你把东西放入模型，视图和控制器文件夹？您是否可以分享一些有关如何修改加载路径以及如何在开发中使用Sprockets或代码重新加载甚至生成器的见解？我刚刚开始使用AngularJS，我真的很喜欢你在那里按功能组织的东西。谢谢！

Answer 1

其中一个Rails原则是约定优于配置，所以如果你按照自己的意愿去做，就会失去很多很酷的东西。想象一下，有人试图维护你的应用程序，他会疯狂地试图弄明白你做了什么。

老实说，如果你想玩rails，试着按照原则去做，试试吧;）

Answer 2

我很确定有一种方法可以破解Rails惯例，但问题不应该是，如果可能的话。我想您应该问问自己这样的文件夹结构的好处是什么，然后在Rails世界中寻找合适的替代方案。但我认为更改文件夹结构并不是一个好主意，因为这是Rails的核心设计决策之一。

相反 - 假设您喜欢这种结构，因为您希望能够非常快速地在特定功能的模型/视图/控制器之间切换我建议您尝试使用模糊搜索等工作流来打开Atom中的文件甚至为您选择的文本编辑器编写扩展名。这样可以保持您的仓库清洁，并且仍然可以加快您的工作流程。

Answer 3

如果你自2008年以来一直在玩Rails，那么你应该完全知道这不是你应该在Rails中做的事情。 Rails是一个固定的MVC框架。当你偏离它的惯例时，你会感受到痛苦，骑行会变得非常粗糙。想象一下像部分查找，路由，加载路径，授权，身份验证等......

据说，构建一个使用微服务对象的架构很容易。这为您提供了两全其美的体验。您可以将这些服务对象视为“功能”。这在复杂的应用程序中是值得的。我现在正在构建一个，我已经有很好的结果将功能分解为小型服务，或者如果你愿意，可以通过控制器与“功能”进行交互。它使测试变得简单，在正确的区域中隔离逻辑，并为可重用性带来奇迹。

例如，功能将更新文档。

class UpdateDocument
  attr_reader :user, :document

  def initialize(user, document)
    @user = user
    @document = document
  end

  def call(params)
    document.update! params.merge(last_editor: user)
    UpdateDocumentJob.perform_later(document)
  end
end

控制器将是：

  def update
    UpdateDocument.new(current_user, @document).call permitted_attributes(@document)
    respond_to do |format|
      format.html { redirect_to :back, success: t('.success') }
      format.js
    end
  end

如何通过功能而不是控制器，模型和视图来构建Rails项目？

3 个答案: