定义“剩余休息时间”的正确方法是对于 Django 用户
我已经实现了一个 UserProfile 模型（正如 Django 1.2 文档所说，这是保存有关用户的附加数据的正确方法），它有一个“remaining_vacation_hours”字段。
在我们当前的系统中，当用户填写休假请求时，应检查剩余的可用时间，以查看他们是否有足够的假期可供使用，否则会警告他们要求的时间超出了他们的假期。
当然，休假时间每年都会补充，因此系统应该检查用户是否会在他们请假的日期累积额外的假期。
只需创建一个 get_remaining_vacation_hours() 方法就足够了，因为将来可能需要添加的其他计算或业务逻辑可以添加到该方法或从该方法调用。
我的问题是，将 get_remaining_vacation_hours() 方法添加到 UserProfile 模型中听起来正确吗？
这似乎有道理，但我想向社区验证一下我并没有忽视针对此类事情的更好实践。欢迎任何想法或建议。
I've implemented a UserProfile model (as the Django 1.2 docs say is the proper way to save additional data about a User) which has a 'remaining_vacation_hours' field.
In our current system, when a user fills out a Time Off Request, the remaining hours available should be checked to see that they have enough vacation to use, or otherwise be warned that they are asking for more than they have.
Of course, vacation hours are annually replenished, so it would be appropriate for the system to check if the user would have additional vacation accrued for the dates they're asking off.
Simply creating a get_remaining_vacation_hours() method would suffice, because other calculations or business logic that might need to be added in the future could be added to or called from that method.
My question is, does it sound correct that the get_remaining_vacation_hours() method be added to the UserProfile model?
It seems to make sense, but I wanted to verify with the community that I wasn't overlooking a better practice for this type of thing. Any ideas or suggestions are welcome.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
首先，我建议采用不同的方法（正如您已经建议的那样）的解决方案，但在不同的类上并将用户实例作为参数传递。这样，您的用户的特征就不会不适用于该抽象级别的每个人。例如，考虑潜在的员工、审计员、合作伙伴、承包商或其他类型的用户。
如果您的系统永远不会有这样的用户（或至少很少），那么我同意 lazerscience 的答案。根据我的经验，即使是具有丰富设计经验的经验丰富的程序员也往往会在用户配置文件中应包含哪些类型的信息和行为方面有所不同。相信你的直觉。如果它“感觉”起来可能不是痛苦或困惑的根源，那就去做吧。另请参阅：杰夫·阿特伍德的 就这些问题提供建议。
First, I would suggest the solution of making a different method (as you've already suggested), but on a different class and pass the user instance as a parameter. That way, your user isn't characterized by something that might not apply to everyone at that level of abstraction. Consider, for example, potential employees, auditors, partners, contractors, or other types of users.
If you're system will never have users as such (or least very few), then I echo lazerscience's answer. In my experience, even well-seasoned programmers with great design experience tend to vary on what kind of information and behavior should go into the user profile. Trust your gut. If it "feels" like it might not be a source of pain or confusion then go for it. See also: Jeff Atwood's advice in matters such as these.
如果您不想修改/继承原始的 User 模型，我想说，如果将该方法添加到您的 UserProfile 中，那完全没问题！
If you do not want to modify/inherit from the original User model I'd say it's totally ok if the method is added to your UserProfile!