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

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

Для обычного пользователя пользовательский интерфейс ЯВЛЯЕТСЯ программным обеспечением. Их не волнует, как хранятся данные, какую платформу вы используете и т. Д. Поэтому, если ваше программное обеспечение будет использоваться людьми, я настоятельно рекомендую начать с пользовательского интерфейса - прототипа или макетов. Покажите это пользователям и получите обратную связь. Затем создайте бизнес-уровень и уровень данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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