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

Question

Например, скажем, у меня есть 3 возможных статуса проекта,

1. открыто
2. Закрыто
3. Неактивный

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

Таким образом, теперь, когда пользователи создают новые элементы проекта, на экране "Добавить новый" должны отображаться только два активных статуса: Открытый и Закрытый. Но теперь давайте предположим, что они редактируют прошлые проекты, статусы которых могут больше не быть активными и доступными. Какие методы используются для включения неактивного статуса в список, по крайней мере до тех пор, пока они не будут повторно сохранены с использованием активного статуса? (Хотя я, вероятно, разрешил бы повторное сохранение со старым статусом.)

Я вижу несколько вариантов, но никогда не решал эту проблему, прежде чем я не уверен, что будет проще всего поддерживать:

1. Всегда выбирайте все возможные статусы из репозитория, а в управляемом коде отфильтровывайте неактивные, кроме статуса, установленного в настоящее время в проекте, и выполняйте привязку, используя этот список.
2. Выберите только активные статусы из репозитория и добавьте (объедините) в управляемом коде статус из проекта в список и свяжите с этим списком.
3. Передайте идентификатор для проекта в SQL, который получает статусы, и используйте его, чтобы объединить текущий статус проекта со списком активных статусов, и связать, используя этот список.

Кажется, что каждый из них может быть достаточно простым для реализации, но, как я уже сказал, я не сталкивался с такой ситуацией. У меня есть несколько списков элементов, которые можно активировать / деактивировать через экраны обслуживания, доступные администраторам; некоторые останутся довольно статичными, но некоторые будут расти бесконечно большими. Варианты 2 и 3 были бы наиболее эффективными, когда списки растут довольно большими, но вариант 1 кажется наиболее простым для реализации.

Я больше беспокоюсь о времени, чем о производительности. Я работаю над приложением ASP.NET, .NET 2.0, C#, веб-формами для пользовательского интерфейса и (I/My)Batis.NET для уровня данных, который взаимодействует с базой данных SQL Server.

Что бы вы мне посоветовали, боги Stackru?

Answer 1

Я обычно использую следующий подход:

1. Метод, который извлекает значения состояния, будет принимать необязательный параметр (или иметь перегрузку в.NET 2.0~3.5), который будет указывать, получать ли неактивные значения или нет. Таким образом, у вас есть выбор: выбирать только активные статусы или все статуи - используйте в соответствии с вашими потребностями.

2. Часто все статусы выбираются, потому что экран будет использоваться для добавления / редактирования / просмотра. Тем не менее, диалоги добавления / редактирования / просмотра запускаются на стороне клиента без каких-либо постбэков. Таким образом, раскрывающийся список состояний будет иметь все значения состояния, а неактивные значения будут выделены определенным классом CSS, поэтому они будут выделены красным цветом, чтобы указать, что они неактивны. В режиме добавления код js (с использованием jquery) будет скрывать неактивные значения состояния. Конечно, в бэкэнд-бизнес-логике есть проверки для проверки правильности кода состояния.