Включение и выключение функций пользовательского интерфейса (или других) на основе дат - запах кода?

У нас есть ужасная система, написанная на ASP.NET 2.0, к которой нам нужно добавить некоторые функциональные возможности. Проблема заключается в том, что определенный продукт имеет функции пользовательского интерфейса, которые должны быть включены для бизнеса, инициированного после определенной даты (а другие отключены), в то время как страница должна выглядеть одинаково для существующего бизнеса.

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

Является ли практика использования основанного на времени пользовательского интерфейса широко распространенной практикой, и если нет, то каковы известные риски, связанные с этим курсом действий?

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

1. зависит от значимых флагов, например, «HAVE_EXPORT» для включения / отключения опции экспорта, а не от странных сравнений дат. Пользовательский интерфейс не имеет дела, зная бизнес-правило о том, что было опубликовано, когда он должен выполнять только свою пользовательскую задачу и подчиняться инструкциям, специфичным для пользовательского интерфейса.
2. Управляться на стороне сервера, чтобы клиент не мог тайно включить функции, за которые он не заплатил.

(Заметим , что обратное - Дис abling особенности после определенного времени - не является крупным нет-нет , если вы не ясно сообщили , что вы продаете времени ограничено пробную версию Создание таких. Бомбы замедленного действия при любых других обстоятельствах заставит людей ненавидеть ты быстрее чем что-либо еще.)

Само требование не проблематично, но есть хорошие и плохие способы его выполнения . Если у вас есть код, скопированный и вставленный повсюду, это выглядит так:

if (businessInitiationDate > cutoffDate)
  enableNewControlsForThisOneLittlePiece();
else
  enableOldControlsForThisOneLittlePiece();

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

В идеале вы хотите, чтобы этот оператор if появлялся в вашем коде ровно один раз , предпочтительно на стороне сервера. Однако вы также хотите избежать дублирования всего приложения и внесения изменений. Найдите общий код и выделите его, а затем создайте небольшие отдельные функции только для разных частей. Затем включите или отключите эти функции из одного центрального места.

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

Тем не менее, одна вещь, которую я могу предложить в качестве улучшения, - это удалить концепцию даты, которая включает элементы управления, но номер версии. Версия устанавливает конфигурацию пользовательского интерфейса (т. Е. У вас есть флаг, скажем, настроенный для NewCustomer, и в будущем его можно расширить, чтобы обслужить дополнительные элементы управления, которые нужны NewNewCustomer, и т. Д.). Это намного легче обрабатывать в коде и пахнет намного приятнее.

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

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

Если изменения связаны с какой-то конкретной бизнес-целью, которая зависит от даты, то это неизбежное зло.

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

Звучит неплохо. Весьма распространено, чтобы пользовательский интерфейс адаптировался к разным пользователям, например, здесь в stackoverflow включаются или отключаются различные функции в зависимости от кармы отдельного пользователя.

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

Известные риски: наибольший риск, вероятно, заключается в тестировании пользовательского интерфейса в различных конфигурациях. Если вы начнете идти по пути включения / отключения функций пользовательского интерфейса для различных групп пользователей, вы можете быстро получить множество возможных конфигураций.

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

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

По сути, в вашей базе данных вы бы применяли дату вступления в силу либо к модулям формы, либо к версиям формы (в данном документе называемые компонентами), сохраняя некоторые метаданные об этих компонентах и ​​их датах начала / окончания. Вам, конечно, понадобятся некоторые данные о ваших пользователях в приложении.

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

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

Вы работаете в APS.NET и JavaScript, но работа фрейма переключения функций Java Togglz специально имеет правило активации на основе даты (и времени!) .