Какой подход к проектированию бэкенда лучше? В чем принципиальная разница между подходами?

Question

[Евгений Журов]

Например, контроллер на Node.js можно написать так:

export class UserController {
    static async login(req, res) {
        try {} catch(e) {}
    }
}

А можно так:

const login = async (req, res) => {
    try {} catch(e) {}
}

const controller = { login }
export default controller

Иначе говоря, в ООП-шном стиле и в функциональном (если я правильно понимаю).
Есть ли принципиальная разница между этими подходами? Сталкивался с кодом написанным и так, и так. И сам писал в одном проекте - так, в другом - иначе. Но то ли не сталкивался с какими-то специфическими для каждого подхода ситуациями, то ли еще что, но не могу для себя решить, какой подход правильнее использовать. Пока возникает ощущение, что всё это - сугубо вкусовщина. Так ли это? И какие еще есть подходы? Что можно почитать/посмотреть на эту тему?

Comments

[Василий Банников]

Если что, первый вариант нельзя назвать оопшным, тк в нём Статик.
А второй нельзя назвать функциональным, тк нет никакой композиции функций

Answer 1

[Александр Нестеров]

Есть ли принципиальная разница между этими подходами?

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

какой подход правильнее использовать. Пока возникает ощущение, что всё это - сугубо вкусовщина.

Это, имхо, вопрос размера проекта и сложности ориентирования в нем. То есть, для простой КРУД-ориентированной системы классы могут быть излишни. Но чем больше логики вынесено за пределы "чтения-записи" из БД, тем ощутимее нужны будут классы.

И какие еще есть подходы

Есть еще процедурное, но оно сейчас используется исключительно для простых программ и на скриптовых языках по типу питона и ванильного js.

Answer 2

[raiboon]

А где вы видели то, что у вас во втором примере?
Так не имеет смысла писать, это не особо "функциональный" подход, главная проблема в том, что нельзя передать заивисимости.
А вот так уже имеет смысл:

export const login = (authService) => (req, resp) => {
	// do something
}

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

Answer 3

[Дмитрий Беляев]

Иначе говоря, в ООП-шном стиле и в функциональном (если я правильно понимаю).

в обоих случаях процедурный стиль

Пока возникает ощущение, что всё это - сугубо вкусовщина

По сути да, чисто вкусовщина.
Хотя второй вариант будет лучше сжиматься terser'ом если поменять

const controller = { login }
export default controller

на export default loginНо для ноды terser редко используют

Answer 4

[Роми]

И какие еще есть подходы?

Laravel например :)

Кроме шуток: - JS - всё-таки язык для фронта, и его основное преимущество над другими языками в том, что он исполняется в любом браузере. Других преимуществ у него попросту нет :D

Comments

[true]

нет

его преимущество - простота
это самый простой язык
и при этом на нем много чего можно сделать

[Vitsliputsli]

true, на любом языке "много чего можно сделать". А в чем заключается "простота" js? Ну если не сравнить с Си или C++, а с каким-нибудь python или php.

[raiboon]

> php
> 2021

я все сказал :)

[Роми]

true, PHP намного проще чем JS, прям вот намного.

[Роми]

Vitsliputsli, в том, что еще совсем недавно приходилось писать

that = this

внутри функции, чтобы передать контекст )))

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

иначе будет наша любимая undefined ))))))))))))

да и вообще, та же самая Vue.js - это по сути попытка хоть как-то подтянуть JS до уровня PHP в плане структурированности, простоты и читаемости кода

а все эти суеверия, что типа "Node - намного быстрее чем PHP" - не более чем суеверия

[Vitsliputsli]

raiboon, и что это значит?

[Роми]

Andrei Brizhak, производительность в чем именно? Node традиционно лидирует например в приложениях работающих через сокеты, но это отнюдь не значит что она лидер во всем. Да и вообще, скорострельность - это сейчас не самый важный параметр - важнее - стоимость поддержки и расширяемость.