|
|
|
Логика в контроллере..
|
|||
|---|---|---|---|
|
#18+
Всем привет. Правильно ли держать бизнесс логику в контроллере, или это порочная практика? Например, у меня так: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Или вот это: Код: java 1. 2. 3. 4. нужно выносить в слой сервиса? В некоторых местах контроллера у меня есть более сложная логика чем просто findOne Как быть? Спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2015, 12:25 |
|
||
|
Логика в контроллере..
|
|||
|---|---|---|---|
|
#18+
JulTПравильно ли держать бизнесс логику в контроллере, или это порочная практика? Для небольших скоропостижных проектов - ОК. Для долгоразрабатываемого продукта - порочная практика. JulTнужно выносить в слой сервиса? Да. JulTВ некоторых местах контроллера у меня есть более сложная логика чем просто findOne Как быть? Спасибо Прочитать про роль и обязанности контроллера в MVC. Держать в контроллере только ту логику, которая этой роли соответствует. Знать о проблеме Anemic Domain Model, когда вообще вся бизнес-логика написана в сервисах, зачастую с нарушением инкапсуляции и всего остального. Service aka Transaction Script это только логика вашей бизнес-транзакции. Поведение же сущностей и других объектов Domain Model имеет смысл держать в классах, полями которых они оперируют. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2015, 12:39 |
|
||
|
Логика в контроллере..
|
|||
|---|---|---|---|
|
#18+
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. а и бизнес логика, которая, в моем случае, сейчас лежит в сервисном слое, верно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2015, 13:35 |
|
||
|
Логика в контроллере..
|
|||
|---|---|---|---|
|
#18+
JulT, можно сделать класс Кофеварка с методом - сварить кофе. А можно класс Кофеварка с сервисным слоем - Взять класс кофеварки + залить воду+ поставить на огонь = сварить кофе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2015, 13:39 |
|
||
|
Логика в контроллере..
|
|||
|---|---|---|---|
|
#18+
JulT, Тут на самом деле всё просто. Если у вас в логике есть некий метод, который манипулирует свойствами определенного класса, то этот метод должен быть в этом классе, а не в "сервисе". Некоторые на столько увлекаются написанием сервисов, что пишут там абсолютно всю логику, в то время когда код становится значительно прощее, если поведение классов находится в самих классах, а не снаружи. В то же время, когда логика затрагивает сразу несколько объектов, она уже в какой-то один из них не помещается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2015, 13:41 |
|
||
|
Логика в контроллере..
|
|||
|---|---|---|---|
|
#18+
Petro123JulT, можно сделать класс Кофеварка с методом - сварить кофе. А можно класс Кофеварка с сервисным слоем - Взять класс кофеварки + залить воду+ поставить на огонь = сварить кофе. Поэтому у нас есть два класса Кофеварка и Бариста. Кофеварка не умеет наливать воду и менять кофе. Бариста не может манипулировать состоянием веществ. Бариста это сервис, который манипулирует кучей сущностей. Кофеварка, это сущность, которая делает одно определенное действие. Хороший пример. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2015, 13:43 |
|
||
|
Логика в контроллере..
|
|||
|---|---|---|---|
|
#18+
есть ещё один аспект. Я веб пришёл с десктопа. Там больше применяется подход без сервисного слоя. Т.к. состояние объектов очень важнО. В веб важна масштабируемость. А её проще всего сделать с импотентными классами (сами не умеют ничего). Поэтому - второй подход чаще. imho В веб нужно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2015, 13:50 |
|
||
|
Логика в контроллере..
|
|||
|---|---|---|---|
|
#18+
BlazkowiczJulT, Тут на самом деле всё просто. Если у вас в логике есть некий метод, который манипулирует свойствами определенного класса, то этот метод должен быть в этом классе, а не в "сервисе". Некоторые на столько увлекаются написанием сервисов, что пишут там абсолютно всю логику, в то время когда код становится значительно прощее, если поведение классов находится в самих классах, а не снаружи. В то же время, когда логика затрагивает сразу несколько объектов, она уже в какой-то один из них не помещается. Т.е., можно сделать так: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Т.е., если добавить в мою домейн модел, бизнесс метод makeCoffee(), тогда это будет считаться Rich Domain Model, правильно мыслю? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2015, 13:52 |
|
||
|
|

start [/forum/topic.php?fid=59&fpage=111&tid=2124638]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
41ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
| others: | 248ms |
| total: | 376ms |

| 0 / 0 |
