Подтвердить что ты не робот

Как использовать слоистую архитектуру spring и все еще следовать объектно-ориентированной структуре?

Я узнал spring и его слоистую структуру (контроллер, сервис и dao)

@Controller("userController")

@service("userService")
@Transactional(     propagation = Propagation.REQUIRED,     isolation = Isolation.DEFAULT,      readOnly = true)

@Repository("userDAO")

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

4b9b3361

ОТВЕТЫ

Ответ 1

В двух словах

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

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

Подробнее

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

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

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

1. Уровень доступа к данным - модель

Это содержит отображение фактических таблиц в классы POJO.

В примере с ERP вы получаете модели: CustomerOrder, CustomerOrderLine

<ч/" > 2. Уровень доступа к данным - репозиторий

Здесь нет ничего, кроме простого CRUD для базы данных с SELECT, INSERT, UPDATE and DELETE SQLs. Вы можете использовать шаблон репозитория в Spring вместе с Spring Data JPA.

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

В этом случае вам может потребоваться написать одну или несколько функций для выполнения сложных запросов запроса. (Предпочтительно в JPQL)

В примере с ERP это место, где вы пишете логику для GetCustomerOrders, GetCustomerOrderByCustomer, GetCustomerOrderLines, GetOrderByStatus

3. Уровень обслуживания

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

Я предпочитаю поддерживать безопасность, реализованную на этом уровне, так как имеет смысл ограничить уровень безопасности на уровне сервиса, который можно повторно использовать в API и Web.

Обратите внимание, что это также должно иметь CRUD, переназначенный из репозитория в соответствии с требованиями бизнес-логики.

(Например, задайте вопрос, требуется ли логика UPDATE для уровня бизнес-логики для этого объекта. Если да, перенаправите UPDATE из репозитория в службу).

В ERP exmple это место, где вы пишете логику для CreateCustomerOrder, ListCustomerOrder, ApproveCustomerOrderLine, ReleaseCustomerOrder,...

Разное Примеры сложной бизнес-логики

Если вы хотите создать Purchase Order для своего поставщика, когда освобожден Customer Order.

Затем это можно сделать, создав службу SupplyChainService, привязанную с помощью Spring AOP к CustomerOrderService.ReleaseCustomerOrder.

Если для создания заказа клиента настроен ППМ,

Вы можете создать службу под названием MrpService и записать в нее логику.

Ключевые примечания. Службы не всегда являются обертками репозиториев, а скорее бизнес-объектами, которые имеют логику. Безопасность должна быть реализована на этом уровне

4. Контроллеры

Контроллеры могут быть разделены на две категории: веб-контроллеры и контроллеры REST. На этом уровне бизнес-логика не должна реализовываться, потому что для вызова в Интернете, а также в уровне API может потребоваться одна и та же логика.

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

Это место, в котором вы также создадите контроллер API, такой как REST, для создания заказа клиента через мобильное приложение или из клиента Windows.

Ответ 2

Spring дизайн приложения и OOD не являются взаимоисключающими.

Типичное приложение Spring (MVC) имеет следующую структуру:

  • Один или несколько классов @Controller. Это точки входа вашего приложения. Они не должны содержать никакой бизнес-логики. Несмотря на имя, я определяю их как V в MVC (Model-View-Controller)
  • Один или несколько классов @Service. Здесь вы разрабатываете свою бизнес-логику (BL). Одно из преимуществ при установке вашего BL заключается в том, что его можно повторно использовать несколькими контроллерами (например, @Controller и @RestController). Они являются C в MVC.
  • Один или несколько классов @Repository, где вы реализуете свой уровень персистентности (база данных, в памяти, независимо...). Кроме того, вы можете реализовать набор классов @Component, которые описывают ваши объекты домена. Это M в MVC.
  • Другие классы, которые вы не можете отображать в шаблоне MVC, например @Configuration, @ControllerAdvice и другие классы конфигурации/управления Spring.

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

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

  • Один вид (@Controller) для каждого актера
  • Один @Service для каждого варианта использования
  • Один @Repository и один @Component для каждого класса домена

EDIT: вы можете найти пример проекта, который я написал для университета здесь. Он реализует то, что я объяснил в последних трех точках, с дополнительным уровнем (между @Controller и @Service), потому что требовалось минимизировать зависимости на уровне C. Концепции по-прежнему применяются.

Ответ 3

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

Почему я говорю, что многоуровневая архитектура не является объектно-ориентированной? Как известно, существует три принципа, которые отличают объектно-ориентированный дизайн: инкапсуляцию, наследование и полиморфизм.

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

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

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

Ответ 4

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

Многоуровневая архитектура

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

Предположим, у вас есть автоматическое резервирование. Обычно, если вы идете с многоуровневой архитектурой (горизонтальной нарезкой), тогда у нас есть другой уровень для выполнения требуемой работы. Но когда дело доходит до вертикальной нарезки, мы идентифицируем разные объекты приложения как резервирование, управление клиентами, управление фондами. Мы будем внедрять эти компоненты, и они свяжутся для создания нашей заявки на резервирование. Здесь необходимо помнить, что внутренний компонент может использовать одну и ту же многоуровневую архитектуру.

Концепции OOPS

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

См. SOLID