Я должен разработать приложение или модель (база данных) сначала? [закрытый]

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

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

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

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

Read требования, и записывают все существительные или "плееры" в документе. Это обычно 80% вещей, которые необходимо сохранить или взаимодействовать с.

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

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

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

Это - то, которое работает так или иначе, но лично я склоняюсь к разработке от UI назад все больше.

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

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

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

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

, Если Вы разрабатываете от базы данных, Вы закончите с конюшней, легкой протестировать базу данных и БОЛЬШОЕ бездельничание получению GUI просто право соответствовать тому, что Вы сделали с DB - который заканчивает тем, что брал намного дольше, поскольку Вы вносите большинство изменений в уровне системы, которую является самым трудным протестировать и имеет самое низкое тестовое покрытие.

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

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

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

Мой ответ нет. Лучше вскочить и получить перемещение быстро.

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

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

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

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

Это - возраст старый вопрос. Ответ, как каждый ответ CS - то, что он зависит. 90% приложений, которые Вы пишете, являются просто формами по данным. Во многих из этих приложений у Вас будут унаследованные приложения с данными, которые необходимо портировать по движению оттуда. Поэтому, ли Вам нравится это или нет, Данные/База данных являются фактором сжатия, и они управляют тем, что Вы делаете. It’s не всего место, чтобы хранить Ваши объекты области, это - Ваш домен, даже при том, что that’s не “right” способ сделать вещи.

В большинстве случаев, I’ve разработал мою модель данных сначала способом, которая берет существующие данные и организует их в реляционную модель. Я тогда делаю основной экранный дизайн. Тогда я создаю свои анемичные Активные бизнес-объекты Типа записи для обеспечения электричеством их. Это ни в коем случае не лучший способ разработать программное обеспечение, но в большинстве случаев, it’s способ, которым вещи будут сделаны или были сделаны. В этих случаях Ваши бизнес-объекты действительно являются просто контейнерами для данных с бизнес-логикой вокруг них, чтобы соединить их проводом до экранов и обеспечить экранная безопасность и целостность данных. Это сосет , но это - каково это.

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

, Если Вам повезло иметь Проект нового строительства, где домен является неотъемлемой частью в приложении и базе данных, просто механизм персистентности для Ваших объектов области, тогда я разработал бы объекты области сначала с помощью Доменного Управляемого Дизайна в поместье TDD и разработал бы экраны и базу данных вокруг объектов области. Я был бы любовь для кодирования как это чаще, но Вы don’t всегда получаете возможность в большинстве мест.

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

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

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

я запустил бы с точно что: Какие данные я хочу обработать?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

, Если Ваш DB разработан правильно в первый раз, все должно просто течь.

РЕДАКТИРОВАНИЕ знать, что я не подразумеваю, что Ваш бизнес-слой или GUI должны быть прямым отражением Вашей модели DB. Иногда это будет подобно, иногда это не будет. Но Ваша модель DB должна быть в состоянии разместить все требования.

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

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

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

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

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

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

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