代码之家  ›  专栏  ›  技术社区  ›  Mohamad

在这三种方法中,哪一种是实施投票制度的最佳方法?[关闭]

  •  5
  • Mohamad  · 技术社区  · 14 年前

    我正在我的网站上实现一个小型投票系统。我想出了三种实现方法,希望你能提供反馈。

    我想让我的用户能够对一些用户生成的内容投几种类型的票。这是一个关于游戏的微问答,与SO和他们的投票系统没有什么不同,规模小得多,专业化程度高。

    在玩弄了下面的方法之后,我无法决定哪种方法是最好的。

    方法1: 使用URL参数和表单

    方法2: 使用URL参数和jQuery

    方法3: 使用上面的乙醚,但从数据库中检索其信息

    架构假定Q和A都是具有不同postTypeId的post对象,并且以下两个表:

    voteTypes(id, voteTypeId, voteName) 
    votes(id, postId, parentId, userId, ownerUserId, voteTypeId) 
    
    1. parentId表示 家长职位。如果投票的职位 上是一个答题帖,它习惯于 确保问题帖子(postTypeId=1) 只能有一个接受的答案。
    2. ownerUserId表示 这个职位的所有者正在投票表决。它 与userId进行比较,后者 来自会话,以确保 用户不能自己投票 帖子。
    3. userId来自会话,表示 投票。

    方法1 当查询在每个帖子上循环时,在视图中创建投票表单。使用隐藏字段捕获数据:

    <input type="hidden" value="@voteTypeId" etc... 
    

    postId、parentId和ownerUserId将来自输出到视图的查询。用户id将来自会话。

    缺点: 一。用户可以操作数据。用户可以接受他没有提出的问题的答案,因为ownerUserId设置在视图级别。 2。笨重:我必须创建尽可能多的表单,因为视图中有帖子。每个职位将有4个表格。一个有10篇文章的页面可以有40个表单。

    优势: 一。很简单。


    方法2 使用带有自定义数据标记的锚和jQuery来构造投票URL。

    <a data-vote-type-id="@voteTypeId" data-post-id="@postId" etc...
    

    ownerUserId、postId、parentId、voteTypeId将来自URL。会话中的用户标识。

    优势 一。重量轻,不变形。一个jQuery调用提交任何投票,如下所示: var data = 'voteTypeId='$(this).data("vote-type-id") 等等,通过ajax提交!

    缺点: 一。JS disabled=不投票。 2。数据可以被操纵,因为它是通过URL发送的。


    方法3 使用方法1或2,仅提交voteTypeId和postId over URL。使用POSITID查询DB并验证正在被投票的POST对象。这样我也可以验证文章的ownerSerid和parentId。

    如果post是一个对象,则创建一个newVote对象。

    用户id将来自会话。postId和voteTypeId将来自URL。 parentId和ownerUserId将来自我查询的post对象。

    优势: 一。由于post的存在而屏蔽了用户操作的数据可以被验证,因此它的ownerserid和parentId也可以被验证。

    缺点: 一。很辛苦。要求数据库查找post并检索在视图级别已经可用的详细信息似乎是不必要的。 2。在某些情况下,数据是非正规化的,所以在成功投票(例如,上投票)之后,我必须通过对象回调(例如,添加1到现有的投票数)来增加POST表,这是另一个具有在视图中已经可用的信息的数据库的调用,然后是控制器级别。


    其他我没有考虑的事情: 一。发现投票是否已经存在并且切换它,这将需要另一个查询。2。验证组合是一个噩梦。

    我正在寻找反馈或其他想法。所以请分享! 非常感谢!

    1 回复  |  直到 14 年前
        1
  •  3
  •   Ivo Wetzel    14 年前

    我会采用方法2,但有一些改变。

    服务器端

    投一票、换一票等的钩子 true false 取决于成功与否。 不能 如果这是您的瓶颈,请忽略这一点,重新考虑数据库模型(如果您无法将其放入关系数据库,请使用noSQL工具)。

    如果你不验证, 我会亲自把你的网站降到被遗忘的程度 ,执行服务器端验证。
    总是 .

    客户端

    客户端从视图中获取信息,然后它可以向服务器发出特定的调用,我们假设这里是一个非恶意用户,如果不是这样的话,他只会在后端失败。

    一旦有人投下/切换,我们将执行以下操作:

    1. 使用视图中可用的数据检查此操作是否可行
    2. 更新UI以反映更改
    3. 将请求发送到服务器
    4. 如果请求返回 我们撤消操作并给出错误消息

    这种方法的好处:

    1. 安全性,我不能仅仅通过发送一些http请求来做不可能的事情
    2. 用户得到快速的响应和对错误的良好反馈
    3. 由于非恶意用户不太可能出现错误,我们不需要在这里进行无休止的检查
    4. 恶意用户,如果用户界面出现故障,我们不在乎后台是否安全。