Дизайн от базы данных сначала до пользовательского интерфейса или как-то иначе?

Question

Всегда ли вы склонны думать о схеме БД, когда начинаете или планируете новый проект, или вы идете другим путем и начинаете проектировать пользовательский интерфейс, а затем опускаетесь в стек?

Или у вас другой способ развития?

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

Я решил, что оба являются лучшими способами в прошлом, и в настоящее время я нахожусь в первом лагере пользовательского интерфейса, но это может и изменится!

Приветствие John

Answer 1

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

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

Прими это как хочешь; это работает для меня довольно эффективно.

Answer 5

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

Answer 6

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

Этот маршрут, начинающийся с базы данных, - это то, как меня учили в школе, и он застрял у меня.

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

Answer 7

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

Answer 8

Сначала выложите свои экраны так, чтобы вы знали, что вам нужно в базе данных.

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

Answer 9

Я только недавно перестал проектировать свою модель данных. Я работал с разработчиком, который включил меня в Domain Driven Design. Теперь я сижу и разрабатываю свою модель Домена, а затем мою модель данных. в то же время я принимаю во внимание любые проблемы, с которыми может столкнуться пользовательский интерфейс.

Answer 10

Сначала смоделируйте домен - это расскажет вам, как построить вашу БД. Далее найдите ваши требования - что нужно делать пользователям с приложением? Это скажет вам, какая функциональность должна существовать. Имея это в виду, вы можете создать свою схему БД и свою модель программного обеспечения (будь то ОО, или функциональная, или любая другая, у вас будет необходимая информация). ПОТОМ создайте симпатичный пользовательский интерфейс, который демонстрирует созданную вами функциональность - конечно, сборка пользовательского интерфейса может также выполняться синхронно с функциональностью, но оба должны появиться после определения того, как выглядит домен.