Задать вопрос
bullock
@bullock

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

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

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

В случае работы с HTTP, расходы на соединения, загрузку данных обычно отъедают большее время работы и скорость кода практически не влияет. (конечно все индивидуально и зависит от задачи)
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 5
Griboks
@Griboks
Вы слишком помешаны на принципах программирования. Это хорошо только в "тяжёлых" больших проектах, но сильно портит маленькие приложения. Любые конструкции нужно вводить по мере необходимости, а не потому что так красиво и правильно.
Ответ написан
Комментировать
@DoctorPro
Просчитайте, а есть ли плюсы от такой архитектуры, SIP, как и другие принципы разработки это, конечно, ориентир, но это не значит, что под условный helloworld надо создавать кучу абстракций в соответствии с принципами. Есть и другие принципы, например, KISS (Keep it simple). Если вы не видите явных плюсов, то может и не надо много абстракций
Ответ написан
Комментировать
Комментировать
qonand
@qonand
Software Engineer
Не стоит зацикливаться на принципах и слепо им следовать. Выбирать между производительностью и поддерживаемостью всегда стоит исходя из особенностей проекта. Стоит задуматься насколько вообще важна поддерживаемость в конкретном проекте и насколько ее могут ухудшить решения улучшающие производительность. Если проект мелкий или разрабатывается как какое-то временное решение, тогда маловероятно что производительный код сильно ухудшить поддерживаемость. Если же проект большой и в будущем в него будут активно вноситься изменения - стоит предпочесть поддерживаемость производительности
Ответ написан
Комментировать
@Xilian
Программист 1С, сетевые технологии, SQL
>>или эффективно и по уродски.

Что за бред?

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

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

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

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

Войдите, чтобы написать ответ

Похожие вопросы