С чего начать с разработки первого веб-приложения на основе базы данных (длинный вопрос)? - PullRequest
6 голосов
/ 27 марта 2010

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

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

Я думаю, что в итоге это будет базовая CMS, для которой я создал набор функций, см. Ниже.

  1. Создание базы данных для хранения структуры сайта (организованной в виде дерева с «группой проектов» -> структура проекта).
  2. Извлечение структуры сайта из базы данных и отображение в виде дерева с использованием базовых технологий переднего плана.
  3. Добавить права администратора / инструменты для изменения структуры сайта.
  4. Автоматическое создание необходимых подстраниц *, когда администратор добавляет новый проект.
    4.1 В каждом проекте будет несколько подстраниц, и содержание каждой подстраницы будет разным.
  5. добавить пользовательские привилегии для назначения прав на чтение и запись для подстраниц.

Что я хотел бы сделать, так это использовать Test Driven Development и создание диаграмм классов как часть моего процесса разработки этого проекта. Моя проблема; Я не уверен, с чего начать. Я читал о модульном тестировании и UML, но никогда не использовал их на практике. Кроме того, никогда раньше не работая с базами данных, как включить эти элементы в модели и тестовые модули?

Заранее благодарим вас за ваш опыт.

Ответы [ 6 ]

7 голосов
/ 27 марта 2010

У меня такое ощущение, что вы пытаетесь схватить слишком много сразу. Можно экспериментировать с базами данных, диаграммами TDD и UML; это само по себе ИМХО будет достаточно для одного проекта. Этот первый экспериментальный проект многому вас научит, на основе которого вы сможете гораздо лучше справляться со следующим проектом. Но я не ожидал бы, что эта первая попытка принесет результаты, которые могут убедить других разработчиков выбрать TDD и / или руководство, чтобы изменить его мышление. Вам нужно сначала понять и испытать вещи, прежде чем вы сможете разумно объяснить их другим.

Советы по модульному тестированию приложений БД см. В следующих разделах:

Я не уверен, что вы подразумеваете под "прототипированием с помощью диаграмм классов". Диаграммы классов хороши для обсуждения / передачи вашего дизайна другим разработчикам и, безусловно, должны быть в наборе инструментов каждого хорошего разработчика. Занятие с кем-то доской, создание эскизов и стирание элементов дизайна на лету - отличный способ прояснить дизайн и силы, влияющие на него. Однако ИМХО это «прототипирование» только в очень широком смысле. Реальным прототипом для меня является код - это единственный способ проверить, действительно ли ваш дизайн действительно работает на практике.

6 голосов
/ 27 марта 2010

Я не уверен, с чего начать.

Мы всегда начинаем с модели данных.

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

Ах, хорошо, есть проблема.

Вы должны начать с данных, потому что все начинается с данных.

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

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

  3. Нарисуйте классы, которые будут реализовывать эти объекты.

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

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

  1. Определите один класс в вашем слое ORM. Вам не нужно быть полным или точным, вам просто нужно что-то, с чем вы можете проверить.

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

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

  1. Посмотрите на отношения на вашей картине. Любая строка. Выберите один случайным образом.

  2. Напишите модульные тесты, чтобы быть уверенным, что вы можете «перемещаться» по этой строке. Из одного объекта извлеките связанные объекты на другом конце строки. Это не должно быть очень сложным, всего несколько строк кода.

  3. Создание «прибора» - тестовых данных, которые вы можете загрузить в базу данных - для представления объектов и их взаимосвязей.

  4. Запустить тест. Если он сломается, обновите определения ORM для правильной поддержки навигации.

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

Теперь вы можете построить свою PHP-презентацию для объектов модели.

2 голосов
/ 27 марта 2010

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

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

Конкретный ответ на использование DB в модульном тесте - вставьте фиктивные строки во время настройки и удалите их на этапах демонтажа. Возможно, вы захотите написать PHP-скрипт для «очистки» БД после тестирования.

Надеюсь, это поможет!

1 голос
/ 28 марта 2010

Почему бы не начать с диаграммы классов? Вы моделируете свое приложение, затем создаете Java-код с JPA-аннотацией, исходящей непосредственно из модели (например, стереотипы также являются аннотациями), и, наконец, вы используете картограф Hibernate / EJB 3 для создания вашей базы данных.

1 голос
/ 27 марта 2010

Мое предложение будет начинаться с ASP.NET MVC. Существует очень хороший пример создания простого веб-сайта с базой данных.

Подробности смотрите здесь: The Nerd Dinner (скачать бесплатно)

http://aspnetmvcbook.s3.amazonaws.com/aspnetmvc-nerdinner_v1.pdf

1 голос
/ 27 марта 2010

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

Это 2 разных подхода к дизайну - вам нужно выбрать один. TDD управляет дизайном, основанным на поведении и тестах. UML, как правило, используется в BDUF (Big Design Up Front) - хотя его можно использовать просто для неформального общения между разработчиками, не будучи частью «дизайна». Суть, однако, в том, что вам нужно решить, как вы хотите разрабатывать свое программное обеспечение. Для меня, как правило, мне удобнее использовать подход TDD, но для хорошо известного домена я могу вместо этого провести сеанс BDUF (хотя я не использую UML).

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

Предполагая, что вы говорите [T | B] DD, а не «модульное тестирование» - вы начинаете с тестов, которые подтверждают поведение, необходимое для вашего приложения. Если вы пойдете по пути [T | B] DD, я, вероятно, полностью пропущу UML. В противном случае, просто запустите генератор UML, когда закончите, и вы получите красивые картинки. ;)

[TestFixture]
public class WhenAddingNewProject {
    [Test]
    public void SubPagesAreCreated() {
       var p = Project.Create("MyProjectGroup\\MyTestProject");

       Assert.IsGreaterThan(p.SubPages.Count, 0);
    }

    [Test]
    public void FirstSubPageIsWikiPage() {
       var p = CreateProject();
       var subPage = p.SubPages[0];

       Assert.AreEqual(subPage.Title == "MyTestProject Wiki");
       Assert.IsTypeOf<WikiSubPage>(subPage);
    }

    [Test(ExpectedException := typeof(SecurityException))]
    public void DefaultsToAdministratorPrivileges() {
       var p = CreateProject();

       var u = User.Login("testuser", "testpassword"); 
       Assert.IsNotNull(u);
       Assert.AreEqual(UserRole.User, u.Role);

       p.Delete();
       Assert.Fail();
    }

    private Project CreateProject() {
       return Project.Create("MyProjectGroup\\MyTestProject");
    }
}

Кроме того, как никогда раньше не работать с базами данных, как мне включить эти элементы в модели и тестовые модули?

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

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