Должен ли я сначала создать приложение или модель (базу данных)?

Ответ 1

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

Ответ 2

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

Если ваша БД правильно спроектирована в первый раз, все должно просто протекать.

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

Ответ 3

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

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

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

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

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

Кроме того, Unit Test все. Вы вносите изменения, и хороший набор Unit Test гарантирует, что вы не нарушаете другие части вашего приложения при внесении изменений.

Ответ 4

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

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

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

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

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

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

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

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

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

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

Ответ 5

Как обоим?

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

Этот подход означает, что:

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

Ответ 6

FWIW, одна из лучших запомнившихся частей Брукса. Мифический месяц месяца:

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

Ответ 7

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

Я бы начал с того, что: какие данные я хочу обработать?

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

Затем вы также должны подумать о том, как вы получаете доступ к этим данным, дает ли он вам какие-либо подсказки для оптимизации в хранилище?

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

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

Ответ 8

Вы можете начать с разработки интерфейса между приложением и моделью и написанием модульных тестов того, как должен себя вести интерфейс. Я обычно беру более гибкий подход и делаю только небольшой предварительный дизайн, прежде чем переходить в код (см. "Прагматичные программисты от Journeyman to Master Tracer Bullets" ).

Ответ 9

По словам Мартина Фаулера, который большинство квалифицированных разработчиков признают в качестве одного из "авторитетов" в этих вопросах, вы сначала разрабатываете свою иерархию OO, а затем "сопоставляете" объекты в своей базе данных, например, шаблон дизайна ActiveRecord...

Ответ 10

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

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

Мой ответ - нет. Лучше прыгать и быстро двигаться.

Я бы, вероятно, разработал приложение в широких штрихах, а затем использовал итеративный подход. Это идея из Agile. На этом предмете много.

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

Некоторые говорят, что есть точка, где это фактически становится невозможным.

Ответ 11

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

Ответ 12

Это тот, который работает в любом случае, но лично я все больше склоняюсь к проектированию из UI.

Основная причина сводится к созданию автоматических тестов поддержки.

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

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

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

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

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

Ответ 13

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

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

В проекте среднего размера я могу пройти более 100 итераций БД, используя инструмент диаграмм ERD, такой как Erwin или Power SQL. Затем нажмите кнопку "forward-engineer", чтобы получить DDL.

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

Затем подключите DAL либо вручную, либо ORM по вашему выбору.

Дело в том, что ни один из инструментов, предназначенных для автоматизации этого процесса, кажется, делает это на 100%. В утопии кода, я думаю, вы могли бы просто создать модель БД и создать идеальную модель домена или наоборот, а затем получить идеальную ОРМ с несколькими щелчками мыши. На самом деле это намного сложнее, чем кажется, и могут возникать тонкие проблемы, такие как производительность и гибкость.

Ответ 14

Моя тактика примерно такая:

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

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

Найдите их атрибуты и создайте модель данных. Попытайтесь вставить это в базу данных. Создайте оттуда.

Для веб-приложений это обычно работает для меня (даже для приложений с более объемным размером). Как вы заметили, я не использовал такие термины, как UML или ERD. Это всего лишь инструменты для общения модели с другими. Powerpoint тоже может это сделать. Это качество конечного продукта, которое считается.

Ответ 15

Для меня это зависит от предыдущего опыта работы с проблемной областью.

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

В первом проекте я с большей вероятностью просто вскакиваю с кодированием, при необходимости подбирая фиктивные данные и узнавая о скрытых измерениях проблемной области, когда я иду. Нередко есть категории данных, которые было бы трудно предвидеть. Когда я их обнаруживаю, я пересматриваю модель данных и продолжаю. Часто этот подход начинается с кодирования script для создания базы данных и ее заполнения. Таким образом, на последующих итерациях я просто изменяю db-build script, запускаю его, и я снова в бизнесе.

Ответ 16

Это старый вопрос. Ответ, как и каждый ответ на CS, заключается в том, что это зависит. 90% приложений, которые вы пишете, являются просто формами данных. Во многих из этих приложений у вас будут устаревшие приложения с данными, которые вы должны переносить через хот оттуда. Поэтому, нравится вам это или нет, Data/Database является сжимающим фактором, и он управляет тем, что вы делаете. Это не просто место для хранения ваших доменных объектов, это ваш домен, хотя это не "правильный" способ сделать что-то.

В большинстве случаев Ive сначала разработала мою модель данных таким образом, чтобы принимать существующие данные и организовывать ее в реляционную модель. Затем я делаю основной экран. Затем я создаю свои анонимные бизнес-объекты типа Active Record, чтобы связать их. Это отнюдь не лучший способ разработки программного обеспечения, но в большинстве случаев его способ, которым все будет сделано или было сделано. В этих случаях ваши бизнес-объекты действительно являются контейнерами для данных с бизнес-логикой вокруг них, чтобы подключить их к экранам и обеспечить целостность данных и безопасность экрана. Это отстой, но это то, что есть.

Если взаимодействие с экраном является самым важным, то, возможно, сначала спроектируйте экран, а затем заложите в него другие объекты. Это будет лучший выбор.

Если вам посчастливилось иметь проект Greenfield, где домен является неотъемлемой частью приложения, а база данных - это просто механизм персистентности для ваших объектов домена, то я бы сначала разработал объекты домена, используя Domain Driven Design, в поместье TDD и разрабатывать экраны и базу данных вокруг объектов домена. Мне бы хотелось чаще писать код, но вы не всегда получаете возможность в большинстве мест.

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