设计问题:你将如何设计一个循环事件系统? [英] Design question: How would you design a recurring event system?

问题描述

如果您的任务是构建一个支持重复事件的事件调度系统，您会怎么做?当一个重复的事件被删除时，你如何处理?你怎么知道未来的事件什么时候发生?

If you were tasked to build an event scheduling system that supported recurring events, how would you do it? How do you handle when an recurring event is removed? How could you see when the future events will happen?

即创建事件时，您可以选择每天重复"(或每周、每年等).

i.e. When creating an event, you could pick "repeating daily" (or weekly, yearly, etc).

请为每个回复提供一个设计.我习惯了 Ruby/Rails，但使用任何你想表达的设计.

One design per response please. I'm used to Ruby/Rails, but use whatever you want to express the design.

我在一次采访中被问到这个问题，但我想不出一个我喜欢的非常好的回答.

I was asked this at an interview, and couldn't come up with a really good response that I liked.

注意:已经问过了/在这里回答.但我希望得到一些更实用的细节，如下所述:

Note: was already asked/answered here. But I was hoping to get some more practical details, as detailed below:

• 如果需要能够评论或以其他方式向重复事件的一个实例添加数据，那将如何工作?
• 事件更改和删除如何工作?
• 您如何计算未来事件何时发生?

推荐答案

我首先将一些时间表达式实现为 由 Martin Fowler 概述.这负责确定计划项目何时实际发生.这是一种非常优雅的方式.我最终得到的只是文章中的内容.

I started by implementing some temporal expression as outlined by Martin Fowler. This takes care of figuring out when a scheduled item should actually occur. It is a very elegant way of doing it. What I ended up with was just a build up on what is in the article.

下一个问题是弄清楚如何存储表达式.另一个问题是，当您读出表达式时，它们如何适应不太动态的用户界面?有人谈论只是将表达式序列化为 BLOB，但很难遍历表达式树以了解它的含义.

The next problem was figuring out how in the world to store the expressions. The other issue is when you read out the expression, how do those fit into a not so dynamic user interface? There was talk of just serializing the expressions into a BLOB, but it would be difficult to walk the expression tree to know what was meant by it.

解决方案(在我的情况下)是存储适合用户界面支持的有限情况的参数，并从那里使用该信息动态生成时间表达式(在为优化而创建时可以序列化).因此，Schedule 类最终具有多个参数，例如偏移量、开始日期、结束日期、星期几等......您可以从中生成时间表达式来完成繁重的工作.

The solution (in my case) is to store parameters that fit the limited number of cases the User Interface will support, and from there, use that information to generate the Temporal Expressions on the fly (could serialize when created for optimization). So, the Schedule class ends up having several parameters like offset, start date, end date, day of week, and so on... and from that you can generate the Temporal Expressions to do the hard work.

关于任务的实例，有一个服务"可以生成 N 天的任务.由于这是与现有系统的集成，并且需要所有实例，因此这是有道理的.然而，这样的 API 可以很容易地用于预测重复，而无需存储所有实例.

As for having instances of the tasks, there is a 'service' that generates tasks for N days. Since this is an integration to an existing system and all instances are needed, this makes sense. However, an API like this can easily be used to project the recurrences without storing all instances.

这篇关于设计问题:你将如何设计一个循环事件系统?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！