powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Java [игнор отключен] [закрыт для гостей] / Логика в контроллере..
9 сообщений из 9, страница 1 из 1
Логика в контроллере..
    #39111961
JulT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Всем привет.
Правильно ли держать бизнесс логику в контроллере, или это порочная практика?
Например, у меня так:

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
@Controller
    public class A {
        @Autowired
        private OrderService orderService;
        @Autowired
        private UserRepository userRepository;

        @RequestMapping(value = "/createOrder", method = RequestMethod.POST)
        @ResponseBody
        public CreateOrderResponse createOrder(@RequestBody CreateOrderRequest request) {
            User user =  userRepository.findOne(request.getUserId());
            if(user == null){
                throw new SomeException(1, "User not found!");
            }
            orderService.createOrder(...);
        }
    }



Или вот это:
Код: java
1.
2.
3.
4.
 User user =  userRepository.findOne(request.getUserId());
    if(user == null){
        throw new SomeException(1, "User not found!");
    }


нужно выносить в слой сервиса?

В некоторых местах контроллера у меня есть более сложная логика чем просто findOne
Как быть? Спасибо
...
Рейтинг: 0 / 0
Логика в контроллере..
    #39111979
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
JulTПравильно ли держать бизнесс логику в контроллере, или это порочная практика?

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

JulTнужно выносить в слой сервиса?

Да.

JulTВ некоторых местах контроллера у меня есть более сложная логика чем просто findOne
Как быть? Спасибо
Прочитать про роль и обязанности контроллера в MVC. Держать в контроллере только ту логику, которая этой роли соответствует.
Знать о проблеме Anemic Domain Model, когда вообще вся бизнес-логика написана в сервисах, зачастую с нарушением инкапсуляции и всего остального. Service aka Transaction Script это только логика вашей бизнес-транзакции. Поведение же сущностей и других объектов Domain Model имеет смысл держать в классах, полями которых они оперируют.
...
Рейтинг: 0 / 0
Логика в контроллере..
    #39112056
JulT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BlazkowiczJulTПравильно ли держать бизнесс логику в контроллере, или это порочная практика?

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

JulTнужно выносить в слой сервиса?

Да.

JulTВ некоторых местах контроллера у меня есть более сложная логика чем просто findOne
Как быть? Спасибо
Прочитать про роль и обязанности контроллера в MVC. Держать в контроллере только ту логику, которая этой роли соответствует.
Знать о проблеме Anemic Domain Model, когда вообще вся бизнес-логика написана в сервисах, зачастую с нарушением инкапсуляции и всего остального. Service aka Transaction Script это только логика вашей бизнес-транзакции. Поведение же сущностей и других объектов Domain Model имеет смысл держать в классах, полями которых они оперируют.
Все поняла, кроме последнего предложения: "Поведение же сущностей и других объектов Domain Model имеет смысл держать в классах, полями которых они оперируют."
И еще, когда говорят о Rich Model подразумевают, что в моей конкретной энтити будут не просто поля с сетерами и гетерами, например:
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
@Entity
@Table(name = "user")
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "id")
    private Long id;

    @Column(name = "first_name")
    private String firstName;
     
    ....
    + set/get


а и бизнес логика, которая, в моем случае, сейчас лежит в сервисном слое, верно?
...
Рейтинг: 0 / 0
Логика в контроллере..
    #39112061
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
JulT,
можно сделать класс Кофеварка с методом - сварить кофе.
А можно класс Кофеварка с сервисным слоем - Взять класс кофеварки + залить воду+ поставить на огонь = сварить кофе.
...
Рейтинг: 0 / 0
Логика в контроллере..
    #39112065
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
JulT,

Тут на самом деле всё просто. Если у вас в логике есть некий метод, который манипулирует свойствами определенного класса, то этот метод должен быть в этом классе, а не в "сервисе". Некоторые на столько увлекаются написанием сервисов, что пишут там абсолютно всю логику, в то время когда код становится значительно прощее, если поведение классов находится в самих классах, а не снаружи.
В то же время, когда логика затрагивает сразу несколько объектов, она уже в какой-то один из них не помещается.
...
Рейтинг: 0 / 0
Логика в контроллере..
    #39112069
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123JulT,
можно сделать класс Кофеварка с методом - сварить кофе.
А можно класс Кофеварка с сервисным слоем - Взять класс кофеварки + залить воду+ поставить на огонь = сварить кофе.
Поэтому у нас есть два класса
Кофеварка и Бариста.
Кофеварка не умеет наливать воду и менять кофе.
Бариста не может манипулировать состоянием веществ.
Бариста это сервис, который манипулирует кучей сущностей.
Кофеварка, это сущность, которая делает одно определенное действие.

Хороший пример.
...
Рейтинг: 0 / 0
Логика в контроллере..
    #39112080
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
есть ещё один аспект.
Я веб пришёл с десктопа. Там больше применяется подход без сервисного слоя. Т.к. состояние объектов очень важнО.
В веб важна масштабируемость. А её проще всего сделать с импотентными классами (сами не умеют ничего).
Поэтому - второй подход чаще.
imho
В веб нужно
...
Рейтинг: 0 / 0
Логика в контроллере..
    #39112087
JulT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BlazkowiczJulT,

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

Т.е., можно сделать так:
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
@Entity
public class CoffeMashine {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "id")
    private Long id;

    @Column(name = "type")
    private String type;

    GET/SET
    .....

    public void makeCoffee(some parameters){
        .......
    } 


Т.е., если добавить в мою домейн модел, бизнесс метод makeCoffee(), тогда это будет считаться Rich Domain Model, правильно мыслю?
...
Рейтинг: 0 / 0
Логика в контроллере..
    #39112091
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123Поэтому - второй подход чаще.
imho
В веб нужно
окапечатка и лишний текст кроме imho)).
...
Рейтинг: 0 / 0
9 сообщений из 9, страница 1 из 1
Форумы / Java [игнор отключен] [закрыт для гостей] / Логика в контроллере..
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]