Как обрабатывать повторяющиеся даты (только даты) в .NET? - PullRequest
4 голосов
/ 15 ноября 2009

Я пытаюсь найти хороший способ обработки повторяющихся событий в .NET, особенно для приложения ASP.NET MVC. Идея состоит в том, что пользователь может создать событие и указать, что событие может повторяться после определенного интервала (например, «каждые две недели», «один раз в месяц» и т. Д.).

Каков наилучший способ справиться с этим? Мой мозговой штурм сейчас состоит в том, чтобы иметь две таблицы: Job и RecurringJob. Задание является «основной» записью и содержит описание задания, а также ключ к тому, для какого клиента он предназначен, в то время как RecurringJob ссылается на задание и имеет дополнительную информацию о частоте возникновения (например, 1 для «один раз в месяц») а также временной интервал (например, «Еженедельно», «Ежемесячно»). Вопрос заключается в том, как определить и установить следующее вхождение задания, поскольку это должно выполняться регулярно. Я видел две последовательности мыслей с этим: эта логика должна либо храниться в столбце базы данных и периодически обновляться, либо рассчитываться на лету в коде.

Есть какие-нибудь мысли или предложения по решению этой проблемы?

Редактировать: это веб-приложение на основе подписки, которое я создаю, чтобы сервисные предприятия могли легко планировать свои обычные повторяющиеся задания и отслеживать своих клиентов. Таким образом, типичное использование может заключаться в том, чтобы создать для г-на Смита задание «подстригать газон», которое происходит каждый месяц. Точная дата не важна - это возможность для клиента видеть, что г-н Смит подрезает свой газон каждый месяц и следить за ним об этом.

Позвольте мне перефразировать вышесказанное, чтобы лучше передать мою идею. Пример использования приложения может быть следующим:

  • Пользователь открывает запись о клиенте для Джона Смита и щелкает ссылку Добавить работу .
  • Пользователь заполняет форму для создания задания с именем «Срезать газон», дата начала которого 15.11.2009 г., и устанавливает флажок, указывающий, что это задание происходит постоянно. Пользователю предоставляется дополнительный экран, запрашивающий частоту выполнения задания. Пользователь указывает (еще не решил, как на данный момент - допустим, выберите списки), что задание выполняется раз в месяц.
  • Пользователь нажимает сохранить.

Теперь, когда пользователь просматривает запись для Джона Смита, он видит, что у него есть задание «Срезать газон», которое происходит каждый месяц, начиная с 15.11.2009. На главной панели инструментов, когда за неделю до предполагаемой даты начала, пользователь видит задание, отображаемое с помощью индикатора, такого как «15.12.2009 - Срезанный газон (Джон Смит)». За неделю до назначенной даты кто-то из компании звонит ему по расписанию, и он говорит, что его не будет в городе до 1 января 2010 года, поэтому он хочет перенести свое назначение на эту дату. Наш пользователь может изменить дату для задания на 1/1/2010, и теперь повторение начнется через месяц после этой даты (например, в следующий раз будет 01.02.2010). Идея заключается в том, что приложение предназначено для таких компаний, как уход за газонами, сантехники, чистящие средства для ковров и т. П., Где точная дата не так важна (поскольку она может меняться и будет меняться, когда люди заняты), главное - дать бизнес показатель того, что ежемесячное обслуживание мистера Смита подходит к концу, и кто-то должен позвонить ему, чтобы определить, когда именно это может быть запланировано. По сути, дайте этим предприятиям возможность отслеживать повторные сделки и узнайте, когда пришло время связаться с клиентом.

Ответы [ 4 ]

2 голосов
/ 15 ноября 2009

Это то, о чем я думал немного раньше - хотя я и не применял это на практике в реальном мире, элементы, с которыми вы работаете, следующие:

  • Описание работы
  • Шаблон повторения
  • Следующий запланированный случай
  • История заданий / происшествий

Пока все просто. Это те вещи, которые хранятся в базе данных, средства для расчета «следующей» даты на основе заданной даты и шаблона повторения, живущего в вашей бизнес-логике.

Ключевая информация для ваших клиентов в целом - это список следующих запланированных событий, при условии, что они поддерживаются правильно (вы создаете новый, когда отмечаете текущий как выполненный), что буду работать. К сожалению, для целей планирования вам, вероятно, понадобится показать несколько следующих событий, и именно в этот момент все становится интересным (-: два варианта: вычислять на лету (я думаю, что это, вероятно, лучше, особенно с некоторым умным) кэшированием ") или предварительный расчет, который снижает общую нагрузку, но требует больше данных для управления и поддержания их в актуальном состоянии, является более сложным (не говоря уже о том, как далеко впереди создание записей в расписании).

Итак - чтобы ответить на ваш вопрос - почему я думаю, что на лету лучше? Ну, в основном, потому что точка «1019» только «фиксированная» является следующим запланированным событием, вы захотите рассчитать свой дневник вперед оттуда на основе его текущего значения (ish), и если он изменится, то вам нужно пересчитывать. Вы можете проявить творческий подход с точки зрения сохранения списка следующих дат, кэшированных для конкретной работы, для повышения производительности по мере необходимости, но с точки зрения действительно постоянного хранения вас интересует только следующая дата.

Несколько заключительных мыслей - во-первых, если дата события произошла (как в вашем вопросе), есть две опции для следующей даты: а) продолжить исходное расписание независимо от изменения (или даже отмены) из - еще одна проблема!) текущее событие или б) график от фактического завершения, т.е. для некоторых вещей мы хотим, чтобы они происходили каждые n недель в определенный день, но, возможно, потребуется время от времени перебирать даты назад и вперед, тогда как для другие вещи, которые мы хотим, чтобы они произошли через 4 недели после предыдущего завершения. Во-вторых, как подсказал Джон, вам следует взглянуть на iCal, не обязательно для реализаций, но, безусловно, чтобы понять элементы того, что может составлять запись календаря и шаблон повторения.

2 голосов
/ 15 ноября 2009

Насколько сложными могут стать ваши правила? Если вы сможете убедить держав, которые должны быть простыми, ваша жизнь станет намного приятнее :) Вы также должны заставить их подписывать документы в различных тестовых ситуациях - если что-то запланировано на 30-е число раз в месяц, следует это произойдет в феврале или нет? По крайней мере, используя даты (без времени), вы должны уйти, не беспокоясь о переходе на летнее время ...

Возможно, вы захотите взглянуть на DDay.iCal или найти другие реализации iCal (RFC 2445) для .NET - но оценить качество библиотеки может быть непросто, так как это сложная область с множество угловых шкафов.

Что касается базы данных, я бы рассчитал ее на лету, если это не окажется слишком болезненным. Очевидно, вам все равно придется где-то использовать тот же код «отработка следующего вхождения», и это устраняет сложность периодического обновления.

0 голосов
/ 15 ноября 2009

Я видел, что это сделано просто на стороне базы данных, и позвольте мне сказать вам, что это становится действительно ужасным.

Я бы предложил иметь какую-то бизнес-модель, которая обрабатывает идею повторяющихся событий (т.е. вычисление на лету из бизнес-модели).

Что касается базы данных, вам, безусловно, нужно будет хранить данные, связанные с вашей бизнес-моделью, но помимо этого вам следует рассмотреть прогнозирование ваших повторяющихся событий (возможно, до года или итак), что позволит использовать внешние по отношению к вашему приложению возможности использовать ваши события. Например, если у вас есть система отчетности, которая должна знать, на кого запланированы люди и т. Д.

0 голосов
/ 15 ноября 2009

Хранение расписания в таблице базы данных или в XML-файле имеет смысл. прежде всего потому, что задание может быть запланировано только приложением asp.net. Событие должно быть инициировано другим приложением - скорее всего, службой Windows, которая проверяет конфигурацию, которая хранится в приложении asp.net.

Что касается структуры таблиц, которая действительно зависит от того, что именно вам нужно запланировать - я представляю, что все, что вам действительно нужно, это идентификатор пользователя, идентификатор задания и дата для выполнения в одной таблице.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...