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

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.

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

Answer 1

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

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

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