Дизайн от базы данных сначала до пользовательского интерфейса или наоборот?
вы всегда склоняетесь к мысли о схеме БД при запуске или планировании нового проекта, или вы идете другим путем и начинаете разрабатывать пользовательский интерфейс, а затем перемещаетесь вниз по стеку?
или у вас есть другой путь развития?
не очень гибкий / водопад/спецификации / истории вопрос просто способ получить ручку, на которую люди опираются при работе над проектами личные / профессиональные или иным образом.
Я решил, что оба являются лучшими способами в прошлое и в настоящее время в первом лагере UI, но это может и изменится!
Ура Джон!--1-->
11 ответов
Я делаю так. Обычно я рисую прототип того, как будет выглядеть экран, а затем пытаюсь разработать модель данных. Вместо того, чтобы идти прямо в базу данных, я нахожу, что это работает намного лучше, так как с моим пользовательским интерфейсом я вижу необходимость в свойствах (или полях в БД), о которых я бы не подумал иначе. Оттуда я разрабатываю модель и отскакиваю назад и вперед, пока оба не удовлетворяют потребностям требования, а затем я беспокоюсь о схемах базы данных. Как правило, хотя сама модель определит схему для меня, так что об этом позаботятся.
для среднего пользователя, UI и программное обеспечение. Им все равно, как хранятся данные, какую платформу вы используете и т. д. Поэтому, если ваше программное обеспечение будет использоваться людьми, я настоятельно рекомендую начать с пользовательского интерфейса - прототипа или макетов. Покажите это пользователям и получите обратную связь. Затем создайте бизнес-уровень и уровень данных.
Я считаю, что это помогает собирать требования. Нетехнические пользователи с большей вероятностью скажут вам: "о, подождите, нам нужно другое поле на этой странице", чем "нам нужен другой атрибут в этой схеме таблицы". Они также могут сказать: "нам нужна еще одна кнопка здесь", что обычно переводится на некоторую дополнительную бизнес-логику и т. д.
Это очень ситуативно. Большая часть моей работы начинается с базы данных, потому что базы данных, над которыми я работаю, являются корпоративными ресурсами - они используются несколькими UI. Было бы вредно иметь БД, разработанную вокруг Капризов конкретного пользовательского интерфейса, который, вероятно, будет часто меняться.
с другой стороны, есть ситуации, когда было бы более полезно сосредоточиться на пользовательском интерфейсе, и пусть дизайн базы данных придет позже-возможно, во встроенном мобильном приложении DB, для пример.
сначала выложите свои экраны, чтобы вы знали, что вам нужно в базе данных.
Если вы начинаете с базы данных, то вы обычно начинаете с набора предположений о том, как будет функционировать приложение.
Я, как правило, начинаю с середины и работаю над тем, что приложение будет делать и как, а затем отскакивать между пользовательским интерфейсом и дизайном базы данных, поскольку они могут информировать друг друга.
Как правило, сначала я начинаю с базы данных и создаю пользовательский интерфейс в соответствии с ней. Обычно есть некоторые назад и вперед, хотя, возможно, мне придется изменить базу данных в соответствии с требованиями пользовательского интерфейса или наоборот.
этот маршрут, начиная с базы данных во-первых, как меня учили в школе и он застрял со мной.
один программист, с которым я работал, начинал с вывода. Он бы начал с выяснения того, что нужно сделать (то есть, какие отчеты должны выйти, etc), затем работайте над тем, какие данные требовались, чтобы туда попасть. UI и база данных были построены одновременно.
в проектах, над которыми я работаю, я нахожу, что пользовательский интерфейс-это то, из чего исходят многие мои требования-это та часть, о которой заботится конечный пользователь (или, по крайней мере, думает).
по сути, я узнаю, что функциональность должен быть первым. Я не имею дела с пользовательским интерфейсом, или как он выглядит, или как он должен быть введен, я имею дело с тем, что хочет сделать пользователь.
затем я строю модель данных вокруг этого. Иногда это очень простая модель данных (особенно если это простое требование, например "воспроизвести фильм"), в других случаях это очень сложно.
только после того, как это было решено, я пытаюсь создать пользовательский интерфейс, который отражает модель и как пользователь ожидает, что ввод в работу.
возьмите это за то, что вы хотите; это работает для меня довольно эффективно.
прежде всего, сосредоточьтесь сначала на обеспечении того, чтобы система решила проблему, которую она призвана решить.
соберите требования для определения рабочего процесса, данных, тонкостей взаимодействия с пользователем и т. д., а затем создайте оттуда.
конечно, вам всегда придется настраивать вещи здесь и там, но из моего опыта я нахожу, что люди, которые подписываются на ту или иную философию (т. е. всегда начинают с БД и создают vs. ui и ныряют вниз) много раз будут в итоге получается решение, которое не соответствует задаче.
сначала смоделируйте домен - это расскажет вам, как построить вашу БД. Найдите свои требования дальше - что пользователи должны делать с приложением? Это скажет вам, какая функциональность должна существовать. С этим в руке вы можете создать свою схему БД и свою модель программного обеспечения (будь то OO, или функциональный, или любой другой, у вас будет необходимая информация). Затем сделайте красивый пользовательский интерфейс, который предоставляет встроенные функции - конечно, UI build can быть сделано в синхронизации с функциональностью, а также, но оба должны прийти после определения того, как домен выглядит.
Я только недавно перестал разрабатывать свою модель данных. Я работал с разработчиком,который включил меня в доменный дизайн. Теперь я сижу и сначала проектирую свою модель домена, а затем мою модель данных. в то же время я принимаю во внимание любые проблемы, которые может представлять пользовательский интерфейс.