我是从我观察到的情况来讲的,可能并不一定是Rails惯例。
例如,当我们做rails g post title content:text
例如,你可能记得它没有default: ''
为标题(字符串)和内容(文本)。这已经暗示我没有关于这个的Rails约定,或者具体地说默认情况下每个属性都被允许为NULL或零。
使用NULL的好处是您可以识别哪些记录具有这些属性设置。
假设我们有一个API服务器。如果客户向我们的API服务器创建一个帖子,我们知道哪些属性有意为其创造价值。比方说,像下面这样:
客户-1的post数据:
post: {title: 'Foo bar'}
- 如果NULL允许的,将创建一个
Post(title: 'Foo bar', content: nil)
- 如果默认: '',将创建一个
Post(title: 'Foo bar', content: '')
客户-2的post数据:
post: {title: 'Foo bar', content: ''}
- 如果NULL允许的,将创建一个
Post(title: 'Foo bar', content: '')
- 如果默认:“”,将创建一个
Post(title: 'Foo bar', content: '')
从以上,请注意,如果我们有默认:“”,那么我们就无法知道如果客户实际上打算有一个空的content
值,因为对于客户端1和客户端2,邮件的结果值content
无论如何都将具有“(空)”。但是,如果我们具有允许NULL的属性,那么我们仍然可以通过未传入参数中的属性来识别客户端是否打算不具有content
值。这是一个重要的用例。
根据您的项目和属性的用途,您可以为该属性使用NULL允许或设置默认空字符串。
现在,随着一个主要问题NULL,允许作为您遇到的是,你不能保证每个值将是一个String
,因此您<%= @user.profile.location.upcase %>
会引发错误的情况下,location
为空或零。
这可能是一个有点讨厌,特别是如果你有喜欢你的实例方法
<%= @user.profile.location.upcase.downcase %>
这将是一个问题,如果@user.profile.location
是无链,因为你必须优雅地确保它赢得了”不会产生错误。如果@user.profile
为零(我们假设你允许@user.profile
为零),这也会是一个问题。而通常情况下,你会做类似于下面的东西,使这项工作:
<% if [email protected]? && [email protected]? %>
<%= @user.profile.location.upcase.downcase %>
<% end %>
这if
条件仍然可以在很只要你有较长链的方法,以确保正常也不会提出任何错误。
使用.try()
可能会“清理”这一点。我特别在模板文件中使用了很多次。解决方案将清洁像下面,虽然有可能混淆对于那些不知道是谁:
<%= @user.profile.try(:location).try(:upcase).try(:downcase) %>
如果任.location
或.upcase
为零,它将返回零,并没有提出任何undefined method ... for NilClass
了。
你可以写这个 –
Amol的验证,谢谢你的回答,但这不是我的问题。我想知道什么是约定和原因。 –
这也一直困扰着我。对于更多可预测的数据(空白为NULL),我总是使用'nilify_blanks'宝石。我知道这并不能回答你的问题,但它更像是一种协议。 –