Оригинал: Ape Logic, добро пожаловать, пожалуйста, сохраните источник для перепечатки. Подписывайтесь на Xiaoq, чтобы изучать Java — самый быстрый способ продвижения.
После того, как многие студенты создают проект, им не терпится начать писать. Код проекта написан не так буднично, как код некоторых фреймворков, а в основном разрабатывается в режиме MVC.
Четкая структура каталогов может помочь другим учащимся легко понять функциональные модули проекта, а также является очень хорошей привычкой поддерживать последовательное общее соглашение в проекте.
Есть две типичные классификации, но и много деталей.
Дизайн по слоям
Этот шаблон обычно многоуровневый в соответствии с основными концепциями MVC.
- Модель (model) представляет собой ядро приложения (например, поля записи базы данных).
- Просмотр отображает данные (записи базы данных).
- Контроллер обрабатывает ввод (записывает записи в базу данных).
С точки зрения разделения проекта, это похоже на следующую структуру каталогов.
Модель
В каталоге домена размещается модельный слой проекта. На практике он также может иметь следующие названия, которые в обычных проектах мало чем отличаются, в проекте лучше сохранить то же значение, чтобы избежать двусмысленности.
-
entityЭто значение более очевидно, то есть значение сущности, наиболее часто используемое -
modelСмысл модели обычно используется для взаимодействия между различными системами. Но если ваша модель очень проста, ее также можно представить непосредственно сущностью. -
domainЭтот диапазон немного великоват и часто используется во многих зарубежных проектах. Это разница в выражении, которое на самом деле похоже на модель. Это имеет больше смысла в контексте DDD.
Поскольку объем модели и домена относительно велик, я обычно использую объект в проекте для представления взаимодействия с базой данных. В ORM, таких как JPA, также выполняется соответствующая обработка. Напримерjavax.persistence.Entityаннотация.
Dao
daoУровень называется уровнем доступа к данным, который называется уровнем доступа к данным.data access object, которая относится к относительно низкоуровневой и базовой операции. В некоторых других фреймворках это называется по-другому.
-
mapperОбычно это каталог, созданный такими фреймворками, как Mybaits, обычно некоторыми интерфейсами. -
repositoryЗначение склада часто используется в jpa.
Dao должен соответствовать принципу минимальной инкапсуляции и теоретически включает только выполнение предложения SQL. Если есть несколько действий доступа к данным, они должны быть инкапсулированы в Service и управляться транзакциями.
сервис и контроллер
Об этом особо нечего сказать, в основном вся важная логика сделана здесь. Сервис используется для логической обработки, а контроллер — для экспозиции интерфейса.
Организовано по функциям
В большинстве случаев мы используем описанный выше режим деления и можем выполнить свою работу. Например, вся обработка данных размещается на уровне Dao, а вся логическая обработка — на уровне Service.
Это прекрасно работает в небольших проектах, но если в проекте сотни или тысячи сущностей, файлы в этих каталогах взорвутся и в конце концов станут неподдерживаемыми.
Другая проблема заключается в том, что простая функция может быть разбросана по нескольким файлам в нескольких пакетах, что затрудняет поддержку крупномасштабных проектов.
У нас есть еще одна идея — группировать по функциям. Например скриншот ниже.
Помещаем аналогичные функции вmodulesв одной папке под. Если этот функциональный модуль относительно велик, мы можем выполнить иерархическое проектирование в рамках функционального модуля.
Например, на картинке выше есть товарный сервис, ему мы присваиваем каталог space goods, а затем разделяем в нем каталоги dao, entity и другие, а для Сервиса и Контроллера мы просто помещаем его во внешний слой , вы можете видеть, что распределение внутри модуля более гибкое.
Преимущества этого очевидны. Функции стали очень концентрированными, и содержимое каждого пакета не влияет друг на друга.
Более того, я могу использовать эту организацию на ранней стадии проекта, чтобы поместить все функции в один проект. Когда период узкого места проекта достигнут, пришло время провести некоторые оптимизации, такие как разделение микросервисов, разделение сервисов и т. д. В настоящее время мы можем быстро разделить сервис, например, выделенный сервис изображений.
резюме
Подводя итог, Сяо Кью считает, что простое использование многоуровневых пакетов — не очень хорошая привычка.
Возможно, вы знакомы с таким проектом управления фоном, есть много полезных шаблонов, просто следуйте простым правилам этих слоев. Это может быть не проблема для работы с некоторыми аутсорсинговыми проектами и выполнения некоторых одноразовых транзакций, но если это относительно большой и долгосрочный проект, этот многоуровневый интерфейс каталогов покажет свои недостатки.
Потому что с увеличением количества посещений и спросом на низкую связанность и высокую связность масштабируемость будет самым важным фактором, ограничивающим развитие проекта.
Многие люди притворяются декадентами, и я советую вам не давать себя одурачить. Не отказывайтесь от каждой мысли о желании учиться, потому что это может быть вашим будущим я, взывающим о помощи. Я Сяо Кью, и я буду прогрессировать вместе с вами. Нетрудно сдаться, но должно быть здорово упорствовать.