Статическое и динамическое управление + На основе ситуации

Question

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

В каком-то проекте могут использоваться не все 20 полей, а, скажем, только 5-6 полей...

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

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

Как более опытные пользователи...Можете ли вы перечислить плюсы и минусы в обоих случаях?..

Спасибо

Answer 1

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

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

Что касается того, куда поместить логику...что ж, имеет смысл извлекать данные, которые определяют, какие поля должны отображаться, когда из базы данных.Но я бы не рекомендовал помещать всю логику, которая фактически отображает страницу, внутрь хранимой процедуры.Скорее, вы бы использовали SP для извлечения данных и использовали свой язык (PHP, C # / ASP.NET, Java Servlet, что у вас есть) для фактической обработки данных и рендеринга страницы.

хтхт.

Answer 2

Никогда не рекомендуется использовать заданное количество полей, как вы описываете (лучше создавать его динамически, но убедитесь, что вы пишете эффективный код).Создавая определенное количество элементов управления, вы ограничиваете себя и создаете большую проблему с обслуживанием.Возможно, вы не видите этого сейчас, но что произойдет позже, если количество элементов управления изменится?

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