Лучшая практика для организации службы, реализации службы и хранилища в приложении с весенней загрузкой - PullRequest
0 голосов
/ 27 декабря 2018

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

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

Различные посты в блогах имеют разные объяснения.Ищу опытного эксперта.

Ответы [ 2 ]

0 голосов
/ 27 декабря 2018

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

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

  2. Но в большинстве случаев вы хотите, чтобы некоторая бизнес-логика выполнялась до / после работы сбаза данных.Вот где включаются классы обслуживания (один из принципов SOLID - это принцип единой ответственности - в одном классе не должно быть операций персистентности и бизнес-логики).Например, вы вызываете метод EmployeeService.save (), чтобы сохранить сотрудника, и этот метод выполняет бизнес-логику (например, проверяет правильность идентификационного номера сотрудника), а затем вызывает класс репозитория (который только сохраняет сотрудника вбаза данных).

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

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

0 голосов
/ 27 декабря 2018

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

2.Используйте класс Service и используйте этот -> Service - это просто класс, где вы пишете свою бизнес-логику, извлекая некоторые данные из классов репозитория (уровень объекта доступа к данным DAO);Это хорошая практика, чтобы держать их отдельно;так что любое изменение в DAO или сервисе не должно влиять друг на друга.

3.Интерфейс обслуживания пользователя и реализовать его и использовать реализацию.

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

Я бы порекомендовал, если у вас есть одна реализация для класса обслуживания, затем перейдите непосредственно к классу вместо создания интерфейса Service и затем отдельного класса Impl;

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