Carrierwave或Dragonfly是什么？

Question

Carrierwave或Dragonfly是什么？

ruby-on-railsrubyfile-uploadrubygemsdragonfly-gem

28

我一直在寻找Rails文件上传工具，其中对我最有吸引力和趣味性的是CarrierWave和Dragonfly。

从我的调查来看，CarrierWave采用更传统的方式，在保存时可以处理文件，而Dragonfly则是中间件，因此可以实现即时处理。

我想知道人们是否有任何性能测试或比较这两个工具的测试的参考资料。

另外，只是好奇人们对两者的意见，以及他们喜欢哪一个，当然要说明原因。

- Danish Khan

4个回答

10

我使用Dragonfly，只是因为CarrierWave停止支持MongoMapper，而且没有一些hack的情况下，Paperclip无法在MongoMapper上工作。

Dragonfly可以实时处理，即

应该用在高速缓存代理之后，例如Varnish、Squid或Rack::Cache之类的代理，这样第一次请求可能需要一些时间，但随后的请求应该非常快速！

- sent-hil

5

Paperclip

Paperclip是一个简单的文件附件库，旨在为Active Record提供支持。它的目标是尽可能简化设置，并尽可能像处理其他属性一样处理文件。这意味着它们不会保存到磁盘上的最终位置，也不会在设置为nil时被删除，直到调用ActiveRecord::Base#save方法。如果需要，它可以根据大小和存在性进行验证。如果需要，它可以将分配的图像转换为缩略图，而前提条件就是安装ImageMagick（对于大多数现代基于Unix的系统来说，这非常容易，只需安装正确的软件包即可）。附加文件保存在文件系统中，并通过易于理解的规范在浏览器中引用，具有明智且有用的默认值。

优点

验证，Paperclip引入了几个验证器来验证你的附件： AttachmentContentTypeValidator AttachmentPresenceValidator AttachmentSizeValidator
删除附件将属性设置为nil并保存。 @user.avatar = nil @user.save
Paperclip适用于使用activerecord的有机Rails环境，而不是所有其他替代方案。对于初学者的Rails开发人员来说，Paperclip更容易处理，同时也为高级开发人员提供了先进的功能。
非常喜欢Paperclip，因为它不需要RMagick，很容易设置为通过Amazon S3发布，并且在模型中声明所有内容（验证等）可以使事情保持整洁。
关于多文件上传和进度反馈，Paperclip和Attachment_fu都是可能的，但通常需要使用iframe和Apache进行一些额外的工作才能使其正常工作。

CarrierWave

这个宝石提供了一种简单而极其灵活的方式来从Ruby应用程序上传文件。它与基于Rack的Web应用程序（如Ruby on Rails）配合得很好。

优点

简单的模型实体集成。添加一个字符串image属性，用于引用上传的图像。
“神奇”的模型方法，用于上传和远程获取图像。
使用标准文件标签和另一个隐藏标签进行HTML文件上传集成，用于维护已上传的“缓存”版本。
创建具有不同尺寸和格式的派生图像版本的直观界面。图像处理工具在幕后得到很好的隐藏。
用于获取图像及其调整大小版本的公共URL的模型方法，以便进行HTML嵌入。
如果使用内置的Rails缓存，则Carrierwave的性能将更好，因为文件可以在不进行任何处理的情况下加载。如果您不进行任何处理，这并不重要。
上传时生成缩略图（省去了CPU时间）
可以直接使用静态/缓存文档中的文件
不需要任何缓存前端
支持各种存储后端（S3、Cloudfiles、GridFS、普通文件），易于扩展到新的存储类型。
最引人注目的事实是它不会使您的模型配置混乱。您可以定义上传器类。它允许您轻松地重用、扩展等上传配置。我们最喜欢的是CarrierWave非常模块化。您可以在本地文件系统、基于云的AWS S3和更多之间轻松切换存储引擎。您可以在RMagick、MiniMagick和其他工具之间切换图像处理模块。您还可以在开发环境中使用本地文件系统，并在生产系统中切换到S3存储。Carrierwave对外部事物（如DataMapper、Mongoid、Sequel）有很好的支持，甚至可以与第三方图像管理（如cloudinary）一起使用。该解决方案似乎覆盖了几乎所有内容，但该解决方案也更加混乱（至少对我来说），因为需要处理更多的代码。必须赞赏CarrierWave采用的模块化方法。它不关心您使用的流行S3客户端，同时支持aws/s3和right_aws。它也是ORM不可知的，不与Active Record紧密耦合。Paperclip的紧密耦合给我们带来了一些麻烦。

缺点

你无法验证文件大小。有一篇维基文章解释了如何处理，但它并不起作用。
当使用MiniMagick（如果您关心内存使用情况，则非常方便）时，完整性验证不起作用。您可以上传一个已损坏的图像文件，CarrierWave会在第一次抛出错误，但下一次会将其吞噬。
您无法删除原始文件。相反，您可以将其调整大小、压缩等。有一篇维基文章解释了如何处理，但同样也没有起作用。
它依赖于外部库，如RMagick或MiniMagick。Paperclip直接使用convert命令行（ImageMagick）进行处理。因此，如果您遇到Minimagick问题（我遇到过），您将花费数小时在谷歌搜索中。截至本文撰写时，RMagick和Minimagick都已被放弃（我曾经联系过Minimagic的作者，但没有得到回复）。
它需要一些配置文件。这被视为优点，但我不喜欢在项目中只为一个gem而使用单个配置文件。对我来说，在模型中配置更自然一些。不管怎样，这是个人口味的问题。
如果您发现了某些bug，并报告它，开发团队确实缺席并且很忙。他们会告诉您自己修复bug。这似乎是一个在业余时间改进的个人项目。对我来说，它不适用于具有期限的专业项目。
不支持mongomapper
为每个生成的文件/缩略图使用存储空间。如果您使用普通文件存储，则可能会用完inode！

Dragonfly

Dragonfly令人印象深刻的地方是，与大多数其他图像处理插件不同的是，它允许从视图进行即时调整大小。
不需要在单独的文件中配置缩略图大小或其他操作，这是一个巨大的时间和烦恼节省者。它使得Rails视图代码如image_tag @product.image.thumb('150x150#')成为可能。
所有魔法都是通过缓存实现的。插件会在请求时生成要处理的版本，而不是在上传时构建，并链接到图像的各个版本。虽然这对于第一次加载来说是个问题，但新创建的图像将被http缓存以供所有后续加载使用，默认情况下使用Rack::Cache，但如果扩展成为一个问题，则可以使用其他更强大的解决方案。

优点

我需要经常更改图片大小吗？例如：如果您想让用户更改其图片的大小（或者您需要在某些其他情况下灵活调整大小），或者需要快速开发。是：Dragonfly 否：Carrierwave或Paperclip
可以轻松与mongomapper一起使用
只要使用缓存代理，性能应该很好
应该可以与mongomapper一起使用（它只扩展ActiveModel）
即时生成缩略图（更容易创建新的布局/缩略图大小）
仅存储一个文件！节省空间
处理是即时进行的（旨在在缓存代理（如Varnish、Squid或Rack::Cache）后使用，因此尽管第一个请求可能需要一些时间，但随后的请求应该非常快）

缺点

如果没有缓存代理，rack::cache或类似工具，则每个请求都会消耗CPU。
如果需要，无法以文件形式访问缩略图。

参考资料

- praaveen V R

2

其他人已经写了相当不错的总结，我只想说从我们的经验来看，Dragonfly的设置需要更多的维护，由于一些开发人员的疏忽，我们也被卡在了很多孤立的图片上，这些图片在原始图片被删除后仍然存在。如果使用普通的carrierwave就不会出现这种情况。

顺便说一句，我们已经迁移到了cloudinary（并且与之一起使用carrierwave），非常满意。

- Roman

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- leifcr · Accepted Answer

根据设置而定。正如Senthil所写，只要您在前面加上缓存代理，Dragonfly就可以正常工作。

但如果您使用内置的Rails缓存，则Carrierwave会表现更佳，因为文件可以在没有任何处理的情况下加载。如果你不做任何处理，那就没关系了。

以下是我在考虑使用Mongomapper项目的图像时对两者进行综合评估的方法：

Carrierwave：

优点
- 上传时生成缩略图（节省CPU时间）
- 可以直接使用静态/缓存文档中的文件
- 不需要任何缓存前端
- 支持各种存储后端（S3，Cloudfiles，GridFS，普通文件），易于扩展到新的存储类型。
缺点
- 上传时生成缩略图（难以生成新的缩略图大小）
- 不支持mongomapper原生
- 每个生成的文件/缩略图都使用存储空间。如果您使用普通文件存储，则可能会用尽inode！

Dragonfly：

优点
- 应该与Mongomapper一起使用，因为它仅扩展了ActiveModel
- 即时生成缩略图（更易于创建新的布局/缩略图大小）
- 只存储一个文件！节省空间：）
缺点
- 如果没有缓存代理，rack::cache或类似的东西，每个请求都会占用CPU。
- 没有办法以文件方式访问缩略图（如果需要）。

最终我最终使用了两者。

未来的愿望是Carrierwave再次支持MongoMapper。在各种情况下使用两者之后，我发现MongoMapper（rails3分支）中的功能始终有效，并且可以使用插件轻松扩展。目前不能说Mongoid是一样的，但这可能会改变。