Вопрос организации архитектуры. Производительность или поддерживаемость?

Question

[bullock]

В процессе написания приложения меня всегда разрывает на то что бы написать красиво и поддерживаемо или эффективно и по уродски. Вопрос в том насколько медленнее становиться приложение если везде использовать абстракции что бы соблюдать SIP?
У меня в одном из приложений есть контроллер Save в котором я считываю поток из HTTP тела сообщения и передаю этот поток другому своему приложению(типо микро сервисы). Кода не много, но наверное его стоило бы разместить в отдельном объекте? Но тогда мне каждый раз при обращении клиентво к этому контроллеру, придется создавать этот объект а это ресурсы.
Что вы делаете в таких случаях?

Answer 1

[longclaps]

мне каждый раз при обращении клиентво к этому контроллеру, придется создавать этот объект

Пул соединений - слышали о таком? Если это действительно надо - так делают.

Comments

[bullock]

Не знал про такой, спасибо, но такой огород городить из за такой маленькой задачи не очень хочется.

Answer 2

[Родион]

При выборе между читаемостью и эффективностью, лучше выбирать читаемость.
Преждевременная оптимизация зло:
- угадать где будет узкое место не всегда возможно
- оптимизация занимает время
- код усложняется

В случае работы с HTTP, расходы на соединения, загрузку данных обычно отъедают большее время работы и скорость кода практически не влияет. (конечно все индивидуально и зависит от задачи)

Answer 3

[Griboks]

Вы слишком помешаны на принципах программирования. Это хорошо только в "тяжёлых" больших проектах, но сильно портит маленькие приложения. Любые конструкции нужно вводить по мере необходимости, а не потому что так красиво и правильно.

Answer 4

[DoctorPro]

Просчитайте, а есть ли плюсы от такой архитектуры, SIP, как и другие принципы разработки это, конечно, ориентир, но это не значит, что под условный helloworld надо создавать кучу абстракций в соответствии с принципами. Есть и другие принципы, например, KISS (Keep it simple). Если вы не видите явных плюсов, то может и не надо много абстракций

Answer 5

[Ерлан Ибраев]

Инфомарция к размышлению

Answer 6

[Максим Федоров]

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

Answer 7

[Xilian]

>>или эффективно и по уродски.

Что за бред?

>>(типо микро сервисы).

Вот это уже по уродски

>>Кода не много, но наверное его стоило бы разместить в отдельном объекте?

У тебя уже микросервис, который должен быть в своем АП и иметь свою иерархию объектов, или в нормальном случае - вообще ее не иметь.