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

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

Вот что мы сегодня рассмотрим:

  • Что такое гибкая разработка?
  • Что такое разработка через тестирование?
  • Модели предметной области для управления данными Java
  • Автономная сущность
  • Однонаправленная связь «один к одному»
  • Самореферентные отношения один к одному
  • Двунаправленная связь «один ко многим»
  • Однонаправленная связь «многие ко многим»
  • Что изучать дальше

Что такое гибкая разработка?

Agile-разработка — это новая методология, стремительно покоряющая отрасль. Эта методология разработки программного обеспечения позволяет нам создавать программу поэтапно с короткими итерациями в течение от 1 до 4 недель. Инкрементная процедура помогает привести процесс разработки в соответствие с потребностями бизнеса.

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

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

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

Что такое разработка через тестирование?

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

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

Процесс TDD состоит из 4 шагов:

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

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

TDD также полезен для отладки. Каждый цикл процесса TDD требует меньше кода, чем традиционный процесс кодирования. Гораздо проще проверить 10-строчную функцию на наличие ошибок, чем полный 1000-строчный проект.

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

Модели предметной области для управления данными Java

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

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

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

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

Домены обычно представляются в виде прямоугольников, соединенных с другими связанными доменами сетью стрелок. В Java домены представлены через классы.

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

Обзор: процесс разработки модели предметной области

Существует много типов моделей доменов:

  • Автономная сущность
  • Однонаправленный один к одному
  • Двунаправленный один к одному
  • Самостоятельная ссылка один на один
  • Однонаправленный «один ко многим»
  • Двунаправленный «один ко многим»
  • Самостоятельная ссылка «один ко многим»
  • Однонаправленный «многие ко многим»
  • Двунаправленный «многие ко многим»
  • Двунаправленная связь «многие ко многим» с атрибутом соединения
  • Ссылки на себя «многие ко многим»
  • Самоссылка «многие ко многим» с атрибутом соединения
  • Наследование одной таблицы
  • Наследование конкретной таблицы
  • Наследование таблицы классов

Каждый домен имеет свои сильные и слабые стороны и подходит для определенных типов проектов. Пять наиболее распространенных моделей предметной области — это автономные объекты, однонаправленные «один к одному», самоссылающиеся «один к одному», двунаправленные «один ко многим» и «многие ко многим».

Общие сведения об именах моделей доменов:

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

Каждая модель требует одних и тех же 7 общих шагов для создания. Давайте углубимся в них.

  1. Объект передачи данных. Разработайте объект, который действует как карта между пользовательским интерфейсом и уровнем объектов доступа к данным. Структура внутренней базы данных не должна раскрываться пользовательскому интерфейсу.
  2. Фальшивая служба. Разработайте фиктивную службу, которая сохраняет данные в базу данных в оперативной памяти.
  3. Имитация пользовательского интерфейса. Разработайте фиктивный пользовательский интерфейс, чтобы продемонстрировать, как мы можем интегрироваться с фиктивным сервисом. Это позволяет команде пользовательского интерфейса сотрудничать с командой разработки службы, показывая, как пользовательский интерфейс взаимодействует со службой.
  4. Уровень ресурсов. Создайте уровень программного обеспечения ресурсов, содержащий программные объекты. Сущности управляются реализацией Hibernate.
  5. Уровень доступа к данным. Создайте программный уровень доступа к данным, обеспечивающий упрощенный доступ к объектам. Этим занимается Spring.
  6. Уровень бизнес-службы. Создайте уровень программного обеспечения бизнес-службы, который управляет подсистемами доступа к данным и позволяет приложениям вызывать уровень доступа к данным. Должен содержать преобразователь для преобразования объектов доступа к данным в сущности.
  7. Уровень представления: создайте уровень программного обеспечения для представления, который использует контроллеры Spring на основе JSON REST для предоставления услуг пользователям.

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

Как настроить рабочее пространство

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

Вам понадобятся следующие инструменты:

  • Eclipse IDE для разработчиков Java EE
  • JDK 1.7
  • Апач Мавен
  • Сервер БД MySql
  • Апач Томкэт

Вам также понадобится zip-архив с исходным кодом из нашей книги Spring-Hibernate на Github.

Затем вам нужно разархивировать эти файлы и импортировать их в Eclipse как проект Maven.

После выбора параметра «Существующие проекты Maven» выберите папку, в которую вы распаковали загруженный файл, и выберите каталог, содержащий POM, как показано ниже.

Отсюда используйте MySQL для создания новой схемы с именем spring в MySQL Workbench.

Затем откройте Tomcat и установите сервер версии 7.0. Затем нажмите Добавить библиотеку -> Система JRE -> Библиотека -> Альтернативная JRE -> Установленные JRE. Установите это по умолчанию, затем нажмите «Готово».

Наконец, добавьте проект Spring OODD в конфигурацию Tomcat. После запуска Tomcat загрузит индексную страницу из web.xml.

Поздравляем, теперь у вас есть рабочее пространство для реализации моделей предметной области Java!

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

Автономная сущность

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

Например, мы можем посмотреть на объект Product с полем String, name.

Сущность и класс

Класс – это техническое представление набора связанных данных. Сущность — это набор данных, который представляет реальный объект или функцию. В Java классы, представляющие концепции или поведение реального мира, являются сущностями.

Разработка объекта передачи данных: автономная сущность

Чтобы создать объект передачи данных для автономного объекта, создайте класс со следующим кодом:

public class ProductDto implements Serializable {
  private static final long serialVersionUID = 1L; private Integer id;
  private String name;

  // getters and setters 
}

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

Однонаправленная связь «один к одному»

Однонаправленные модели «один к одному» включают два отдельных объекта, в которых данные и сервис могут перемещаться только в одном направлении. Как только данные отправляются дочернему объекту, они не могут вернуться к родительскому объекту, поскольку в дочернем объекте нет связи с родителем.

Например, представьте, что у нас есть программа доставки в книжный магазин, представленная однонаправленной моделью «один к одному» с двумя сущностями, Book и Shipping. Объект Book имеет идентификатор и поле String name. Аналогично, объект Shipping имеет идентификатор и поле String city. Экземпляр Shipping должен присутствовать в экземпляре Book. Book — это владеющая сторона отношений. Он может пройти Shipping, но Shipping не может пройти Book.

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

Разработка объекта передачи данных: однонаправленная связь «один к одному»

Чтобы создать объект передачи данных в однонаправленном отношении «один к одному», вы будете использовать следующий класс BookDto:

public class BookDto { 
  private Integer id; 
  private String name; 
  private String city;
 
  // getters and setters 
}

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

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

Самореферентные отношения один к одному

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

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

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

Разработка объекта передачи данных: связь «один к одному» с самоссылкой

Для самореферентных отношений один к одному наш объект передачи данных будет выглядеть так:

public class StudentDto {
    private Integer id;
    private String name;
    private String mentorName;
    
    // getters and setters
}

Обратите внимание, что у нас есть id, name и mentorName, но не включена идентификация объекта наставника.

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

Двунаправленная связь «один ко многим»

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

Например, рассмотрим программу, которая перечисляет характеристики предмета с двумя сущностями Item и Feature. Сущность Item имеет идентификатор и поле name типа String. Сущность Feature также имеет идентификатор и поле number типа String. Каждый экземпляр Item должен содержать ссылку хотя бы на один. Точно так же каждый экземпляр Feature должен быть связан с одним экземпляром Item.

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

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

Разработка объекта передачи данных: двунаправленная связь «один ко многим»

Для двунаправленной связи «один ко многим» наш объект передачи данных будет выглядеть так:

public class ItemDto {
    private Integer id;
    private String name;
    private List<String> featureList;
    
   // getters and setters
}

Объект передачи данных Item имеет идентификатор, имя Item и список имен String Feature. Использование списка имен Feature позволяет нам связать несколько объектов Feature с нашим одним Item.

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

Однонаправленная связь «многие ко многим»

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

Например, представьте, что вы создаете простую программу для социальных сетей, которая позволяет родительской сущности User связываться с дочерней сущностью Group. Сущность User имеет идентификатор и поле имени типа String. Сущность Group также имеет идентификатор и поле имени типа String.

У каждой связи «многие ко многим» есть родитель. В этом примере Пользователь является родителем. Каждый экземпляр User связан по крайней мере с одним экземпляром Group. Многие экземпляры User могут быть связаны с одним и тем же экземпляром Group.

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

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

Разработка объекта передачи данных: однонаправленная связь «многие ко многим»

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

public class UserDto {
    private Integer id;
    private String name;

    // getters and setters
}

public class GroupDto {
    private Integer id;
    private String name;

    // getters and setters
}

public class UserGroupDto {
    private UserDto userDto;
    private GroupDto groupDto;
    
    // getters and setters
}

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

Что изучать дальше

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

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

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

Удачного обучения!

Продолжить чтение о Java, Spring и архитектуре программного обеспечения на Educative

Начать обсуждение

Почему вам нравится использовать Agile? Была ли эта статья полезна? Дайте нам знать в комментариях ниже!