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

Question

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

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

Каковы наилучшие методы? Что бы вы построили первым и почему?

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

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

Какие преимущества/недостатки имеют каждый вариант?

Answer 1

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

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

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

Some people say there is a point where it actually becomes impossible.

Answer 4

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

Answer 5

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

Answer 6

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

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

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

Answer 7

Как насчет обоих?

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

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

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

Answer 8

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

Answer 9

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

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

Answer 10

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

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

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

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

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

Answer 11

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

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

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

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

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

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

Answer 12

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

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

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

Answer 13

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

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

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

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

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

Answer 14

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

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

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

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

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

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

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

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

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

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

Answer 15

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

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

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

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

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

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

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

Answer 16

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

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

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

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

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

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