我试图找出一种处理.NET中重复事件的好方法，特别是对于ASP.NET MVC应用程序。这个想法是用户可以创建一个事件并指定事件可以在特定间隔后重复发生（例如“每两周一次”，“每月一次”等等。）
解决这个问题的最佳方法是什么？我现在的头脑风暴是有两张桌子：Job和RecurringJob。工作是“主”记录，具有工作描述以及客户的关键，而RecurringJob链接回工作，并有关于发生频率的其他信息（例如1表示“每月一次”）以及时间跨度（例如“每周”，“每月”）。问题是如何确定和设置下一次出现的工作，因为这必须是定期完成的事情。我已经看到了两条思路：这个逻辑应该存储在数据库列中并定期更新，或者在代码中动态计算。
有关解决这个问题的任何想法或建议吗？
编辑：这是针对我正在创建的基于订阅的Web应用程序，让服务企业可以轻松安排他们常见的重复性工作并跟踪他们的客户。因此，一个典型的用途可能是为史密斯先生创造一个每月发生的“割草坪”工作确切日期并不重要 - 这是客户能够看到史密斯先生每个月都要割草坪并跟进他的能力关于它。
让我重新阐述上述内容，以更好地传达我的想法。应用程序的示例用例可能如下：
现在，当用户查看约翰史密斯的记录时，他们可以看到他有一份工作，“剪草坪”，从2009年11月15日开始每个月发生一次。在主仪表板上，当它在假定的开始日期之前一周时，用户看到显示的作业带有指示符，例如“12/15/2009 - 割草坪（John Smith）”。在截止日期前一周，公司的某个人打电话给他按时间表安排，他说他将在2010年1月1日之前离开城镇，所以他希望他的预约在那个日期重新安排。我们的用户可以将作业的日期更改为2010年1月1日，现在重复将从该日期开始一个月（例如，下次将是2010年2月1日）。这背后的想法是，该应用程序的目标是草坪护理，管道工，地毯清洁剂等企业，其中确切的日期不重要（因为它可以并将随着人们的忙碌而改变），关键是给予该业务是史密斯先生每月服务即将到来的指标，有人应该给他一个电话，以确定何时可以安排。实际上，这些企业可以通过这种方式跟踪重复业务，并了解何时与客户进行跟进。
答案 0 :(得分：2)
您的规则有多复杂？如果你能说服那些让事情变得简单的人，那么你的生活会更加愉快:)你也应该让他们在各种测试情况下签字 - 如果某事定于每月30日发生一次，应该它发生在二月份还是没有？至少通过使用日期（没有时间）你应该逃脱而不用担心夏令时......
您可能希望查看DDay.iCal或查找.NET的其他iCal（RFC 2445）实现 - 但判断库的质量可能会非常棘手，因为它是一个复杂的区域，有大量的角落案例
就数据库而言，我会动态计算它，除非证明太痛苦。你显然必须在某处仍然使用相同的“找出下一次出现的”代码，并且它消除了定期更新的复杂性。
答案 1 :(得分：2)
这是我之前想过的 - 虽然我没有在现实世界中付诸实践，但你正在使用的元素如下：
到目前为止，这么容易。这些是存储在数据库中的东西，是根据给定日期计算“下一个”日期的方法，以及存在于业务逻辑中的重复模式。
您的客户一般的关键信息是下一次计划发生的列表，只要这些信息得到正确维护（当您将当前标记为已完成时创建一个新的）那可行。不幸的是，为了安排的目的，你可能需要能够显示下几个出现的事情，这就是事情变得有趣的地方（ - ：两个选择：动态计算（我认为这可能更好 - 特别是有一些聪明的“缓存） “）或预先计算的总负载较少，但需要管理和保持更新的数据更加复杂（除了考虑创建计划条目的时间之外）。
所以 - 回答你的问题 - 为什么我认为在飞行中会更好？好吧，基本上因为仅“固定”点是下一个预定事件，你将要根据当前值（ish）从那里计算你的日记，如果它发生了变化那么你需要重新计算。您可以在保留特定作业缓存的下一个日期列表方面发挥创意，以便根据需要提供性能，但就真正持久存储而言，您只对下一个日期感兴趣。
最后几个想法 - 首先如果发生的日期发生了变化（如你的问题），下一个日期有两个选项，a）继续原始时间表，无论是否改变（甚至取消） - 另一个挑战！）当前事件或b）实际完成时间表，即某些事情我们希望它们在某一天每n周发生一次，但可能需要不时地来回摆动日期而不是我们希望它们在上一次完成后4周发生的其他事情。其次 - 根据Jon的提示 - 您应该查看iCal，不一定是为了实现，但肯定是为了帮助理解可能构成日历条目和重复模式的元素。
答案 2 :(得分：0)
将计划存储在数据库表或xml文件中是有意义的。主要是因为作业只能由asp.net应用程序安排。该事件必须由另一个应用程序触发 - 很可能是一个Windows服务，它检查asp.net应用程序存储的配置。
表的结构实际上取决于你需要安排的内容 - 我想你真正需要的只是用户ID，作业ID和在一个表中执行的日期。
答案 3 :(得分：0)
我已经在数据库方面看到过这样做了，让我告诉你它真的真的丑陋。
我建议使用某种商业模式来处理重复发生的事件（即从商业模式中即时计算）。
就数据库而言，您肯定需要存储与您的业务模型相关的数据，但除此之外，您应该考虑预测您的定期事件（可能长达一年）或者），这将允许您的应用程序外部使用能够使用您的事件。例如，如果您的报告系统需要知道人们的安排等，