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

Question

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

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

Answer 1

Пользовательский интерфейс первый.

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

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

Редактировать: Как уже отмечали другие, вам необходимо начать с примерами использования / пользовательскими историями. Дизайн пользовательского интерфейса и базы данных, в зависимости от того, в каком порядке вы их выполняете, должен происходить только после , когда вы знаете, что и для чего пытается сделать ваше программное обеспечение.

Редактировать Брайаном Окли:

_{(источник: gapingvoid.com )}

Answer 2

Поставьте пользователя на место, которое он заслуживает. Дизайн пользовательского интерфейса первый.

База данных является лишь следствием потребностей пользователя.

Answer 3

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

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

Начните с объектов.

UPDATE:

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

Answer 4

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

Answer 5

Вы бы построили дом без фундамента? Проектирование базы данных - не самое интересное, но это основа большинства бизнес-приложений, и если вы ошибетесь, это станет самым дорогостоящим для исправления и самым дорогим для обслуживания.

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

Answer 6

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

прочитайте это, это хорошая техника. DDD - Дизайн драйвера домена

Answer 7

Ваш вопрос очень субъективен.

Мое мнение (и это просто так) состоит в том, что база данных и базовая структура должны стоять на первом месте.Часто бывает полезно положить клавиатуру и мышь и скомпилировать некоторые заметки на бумаге.

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

Этот метод работает для меня в разработке приложений.

Answer 8

Все приведенные выше ответы направлены на вашу проблему в правильном направлении. Тем не менее, я бы тщательно следовать SDLC. Это поможет вам понять необходимость решения проблемы. Затем идет сбор требований, за которым следует разработка либо пользовательского интерфейса / базовой структуры, которая поддерживает пользовательский интерфейс. Это процедура, но в итоге вы выиграете.