设计问题：你将如何设计周期性事件系统？ [英] 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.

解决方案case）是存储适合用户界面将支持的有限数量的情况的参数，并且从那里使用该信息来即时生成时间表达式（当创建用于优化时可以序列化）。所以，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.

对于有任务的实例，有一个'service'可以生成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屋！