为什么要在 Rails 中建立友谊进行社交联系?
查看了很多有关 Rails 中社交链接系统的教程。我注意到,似乎一致使用朋友作为用户对象的别名,并使用连接模型“友谊”。
我一开始就遵循了这一点,但随着我继续前进,它似乎让像 create.friend
这样的东西变得非常迟钝。现在在我的示例中,我使用术语“联系人”和“连接”...当我列出用户的所有联系人时,我希望通过联系人控制器和视图( /contacts 、 /contacts/搜索、/contacts/create 等...)但是所有的琐事实际上都涉及连接(友谊)表...这开始看起来真的很倒退。
为什么要这样做呢? 我看到的唯一好处是能够说出“contact.email”之类的内容 但我不确定我的代码中额外的抽象和体操是否值得。我很乐意说 contact.user.email。
链接到联系人页面? link_to contact.user
(对吗?)
如果我只有一个具有标准、明显、粗略结构的模型“联系人”并放弃用户模型的这种别名,有什么问题吗?坦率地说,除了身份验证之外,我根本没有看到弄乱用户模型有什么好处……我将用户的所有信息都放在配置文件中。
或者我错过了什么?
更新:我似乎不清楚,所以我会详细说明。
计划 A:
def contact
belongs_to :user
belongs_to :connection, :class_name => 'User', :foreign_key =>'contact_id'
validates_uniqueness_of :contact_id, :scope => :user_id, :message => ' allready one of your contacts.'
attr_accessor :invite
end
然后按照正常的 CRUD 进行操作。转到我的“联系人”页面将显示我的所有联系人以及正常的增删改查操作等...为了获取联系人的电子邮件,在这种情况下我会说: contact.connection.email
然后我做了一些阅读并看到其他人正在这样做:
class Connection < ActiveRecord::Base
belongs_to :user
belongs_to :contact, :class_name => 'User', :foreign_key =>'contact_id'
validates_presence_of :user_id
validates_presence_of :contact_id
validates_uniqueness_of :contact_id, :scope => :user_id, :message => ' allready one of your contacts.'
attr_accessor :invite
end
但是然后使用联系人控制器(朋友控制器)将数据传递到这里。唯一的好处似乎是你可以说 contact.email...但它使联系人控制器中的所有内容都变得奇怪恕我直言。 EG:
http://railsforum.com/viewtopic.php?id=16760
我是想知道为什么会出现明显的脱节?
更新 2:
所以我明白了...联系人必须是对用户模型的引用...无法回避这一点。无论如何,3步。然而,当我尝试沿着这条路径执行时,我仍然对一些要点感到困惑:
使用 contacts_controller.rb 和这样的代码是否违反了 mvc:
# in contacts_controller.rb
def destroy
@connection = Connection.find(params[:id])
@connection.destroy
respond_to do |format|
format.html { redirect_to :action=>'index' }
format.xml { head :ok }
end
end
然后当我尝试执行 form_for @ 时,它会变得很奇怪连接、路由错误等等。 我知道我正在绞尽脑汁地思考这个问题,并且非常感谢迄今为止的所有反馈。
更新 3:
这里举例说明了我对这些关系感到困惑的一个实际例子:
<% @contacts.each do |contact| %>
<li><%= contact.email %> <%= link_to 'Remove Contact', contact.connection, :confirm => 'Are you sure?', :method => :delete %></li>
<% end %>
当迭代用户的联系人时,如何巧妙地调用在列表中显示此联系人以进行删除的连接?也许我应该迭代用户的连接,拉取connection.contact.email来显示电子邮件?
Looking at a lot of tutorials on social linking systems in rails. I notice that there seems to be a consistent use of friends as alias for user objects, with a join model "friendships".
I followed this at first, but as I go forward it seems to make things like create.friend
really obtuse. Now in my example, I'm using the term "contact" and "connection"...When I'm listing all of a user's contacts, I expect to do this through the contacts controller and views ( /contacts , /contacts/search, /contacts/create, etc.. ) but all the crud really deals with the connection (friendship) table...this starts seeming really backwards as I go.
Why is it done this way?
The only benefit I see is being able to say something like "contact.email"
But I'm not sure the additional abstraction and gymnastics in my code are worth it. I'd be just as happy to say contact.user.email.
Link to a contacts page? link_to contact.user
(right?)
Is there any foul if I just have a model "contacts" with standard, obvious, crud structures and forgo this aliasing of user model? Frankly, I don't see a lot of gain in messing with the user model at all for much more than authentication...I'm putting all info for user in a profile.
Or am I missing something?
UPDATE: I seem to be being unclear, so I'll elaborate.
Plan A:
def contact
belongs_to :user
belongs_to :connection, :class_name => 'User', :foreign_key =>'contact_id'
validates_uniqueness_of :contact_id, :scope => :user_id, :message => ' allready one of your contacts.'
attr_accessor :invite
end
Then follow with normal CRUD for this. Going to my "contacts" page will show all my contacts with normal crud operations, etc...To get a contact's email, I would, under this scenario say : contact.connection.email
Then I did some reading and saw that everyone else was doing this:
class Connection < ActiveRecord::Base
belongs_to :user
belongs_to :contact, :class_name => 'User', :foreign_key =>'contact_id'
validates_presence_of :user_id
validates_presence_of :contact_id
validates_uniqueness_of :contact_id, :scope => :user_id, :message => ' allready one of your contacts.'
attr_accessor :invite
end
But then using a Contacts controller (friends controller) to hand the crud here. The only benefit seeming that then you can say contact.email...but it makes all the crud in the contacts controller strange imho.
EG:
http://railsforum.com/viewtopic.php?id=16760
I was wondering why the apparent disconnect?
UPDATE 2:
So I get it...a contact has to be a reference to the user model...no getting around that. 3 steps regardless in that event. However I'm still confused on a few of the fine points when I try to execute along this path:
Is it a violation of mvc to have contacts_controller.rb with code like this:
# in contacts_controller.rb
def destroy
@connection = Connection.find(params[:id])
@connection.destroy
respond_to do |format|
format.html { redirect_to :action=>'index' }
format.xml { head :ok }
end
end
And then it gets odd when I try to do form_for @connection, routing errors and all.
I know I'm kitchen-sinking this question and really appreciate all the feedback so far.
UPDATE 3:
A practical example of the confusion I'm having with these relationships is exemplified here:
<% @contacts.each do |contact| %>
<li><%= contact.email %> <%= link_to 'Remove Contact', contact.connection, :confirm => 'Are you sure?', :method => :delete %></li>
<% end %>
When iterating through a user's contacts, how can I artfully invoke the connection that brings up this contact in the list to target for delete? Maybe I should just be iterating through a user's connections, pulling the connection.contact.email to display the email?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我不确定我完全理解你的问题,但希望这足以让你回答你的问题,或者以更容易回答的方式发布它。
您将友谊关系建模为连接模型的原因是友谊是有方向的,就“因为我与你有友谊并不意味着你与我有友谊”而言。如果您考虑我与您建立友谊的情况,那么在您确认友谊并创建指向另一个方向的关联之前,它不一定有效。
将友谊建模为单独实体的另一个原因是,它可以让您丰富模型,因此您还可以包括您如何认识此人,甚至是介绍您的人的链接。
当您创建模型时,您不必将它们视为与控制器是 1-1 的。您的资源与您的模型是分开的......
在许多应用程序中,您有一个用户模型和一个配置文件模型。它们通常具有一对一的关系,人们常常想知道为什么不将它们建模为一个实体。老实说,没有具体的理由说明为什么您不能为同一个实体建模,但是将它们分开有一些好处。首先,您可以删除用户的登录凭据而不删除他们的个人资料(如果有人想删除他们的帐户,但您不想/不需要删除他们的内容,这很好。)例如,您删除了您的 Facebook 帐户和您的带标签的照片仍然会显示您的名字,但不会显示您的个人资料的链接(我不知道这是否真的是如何工作的,这只是一个例子。)还有其他更软的原因,例如单一责任、关注点分离等。 ..这是“良好实践”,有望使您的应用程序更易于维护。
我希望这对您有所帮助,如果您还有任何其他问题,请发表评论,我会更新这篇文章。
I'm not sure I fully follow your question, but hopefully this will give you enough to either answer your question is post it in such a way where it's more answerable.
The reason why you would model the friendship relationship as a join model is that friendships are directional, in so far as "because I have a friendship with you doesn't mean that you have a friendship with me". If you consider the case where I create a friendship with you it's not necessarily valid until you have confirmed the friendship and created the association that points in the other direction.
Another reason for modelling the friendship as a separate entity is that it lets you enrich the model, so you could also include how you know the person, or even a link to the person who introduced you.
When you create models you shouldn't necessarily think of them as being 1-1 with controllers. Your resources are separate from your models...
In many applications you have a user model and a profile model. These often have a 1-1 relationship and people often wonder why they are not modeled as one entity. To be honest, there's no concrete reason as to why you can't model as the same entity but there are a few benefits to keeping them separate. For a start you can delete a users login credentials without deleting their profile (this is great if someone wants to delete their account, but you don't want to/need to delete their content.) For example you delete your facebook account and your tagged photos will still show your name, but not a link to your profile (I don't know if this is actually how it works, it's just an example.) There are also other softer reasons like single responsibility, separation of concerns etc... which are "good practices" and should hopefully make your application easier to maintain.
I hope this helps a little, if you have any further questions leave a comment and I'll update this post.
加入模型的存在有一个主要原因,即一个用户可以成为多个人的朋友。如果您不希望用户共享许多联系人,我会取消加入。
The join model is there for one main reason, a user can be friends to multiple people. If you don't expect users to share many contacts, I would get rid of the join.