В чяти адово завоняло пыхапэ

вот да.

Опять, хочу заметить.

вот да. [2]

1. ок, давай другими словами. я спрашиваю - нахера ты тащишь в гошку mvc? зачем в гошке чужая раковая опухоль? 2. суть в декларативщине, но ты по привычке привязал к контроллерам 3. да. мы делаем интерфейс, убираем оттуда Init() и ждём инициализированный инстанс 4. https://github.com/smallnest/go-web-framework-benchmark#basic-test он вот просто среди прочей серой массы, даже не свалился в говно и не начал бороться за первенство

1. Та мвц понятное дело не катить на бекенде с рестом, тем более на го. Я просто раньше кормился будучи разработчиком на дотнете. Когда хтмл рендерили на сервере, поступал запрос, он обрабатывался. Формировался респонс и передавался шаблонизатору, который генерил страницу на основе ViewModel. Сейчас страницы на сервере генерят только пхпшники. 2. Ну блин, можно назвать не контроллер, а "экшн" или "РеквестПроцессор" какой-то 3. К сожалению, когда мы получаем информацию о типе, в го нет конструкторов, потому эти значения можно получить только лишь экспортируя экземляр типа через переменную пакета, либо придумывать свои инициализаторы. 4. Та похер на те бенчмарки. 99% обработки запроса занимает IO, а не парсинг хттп-запроса

ребят, а что вы вообще под mvc то понимаете? присутствие структуры с названием Controller?

1. Та мвц понятное дело не катить на бекенде с рестом, тем более на го. Я просто раньше кормился будучи разработчиком на дотнете. Когда хтмл рендерили на сервере, поступал запрос, он обрабатывался. Формировался респонс и передавался шаблонизатору, который генерил страницу на основе ViewModel. Сейчас страницы на сервере генерят только пхпшники. 2. Ну блин, можно назвать не контроллер, а "экшн" или "РеквестПроцессор" какой-то 3. К сожалению, когда мы получаем информацию о типе, в го нет конструкторов, потому эти значения можно получить только лишь экспортируя экземляр типа через переменную пакета, либо придумывать свои инициализаторы. 4. Та похер на те бенчмарки. 99% обработки запроса занимает IO, а не парсинг хттп-запроса

1. забывай наконец-то mvc %) 2. это всё вытекает из вопроса 1. 3. wuuuuuuut? о чём ты блин 4. далеко не всегда.

а то я вот в go style пилю хэндлеры с res/req с сервисом внутри и это mvc

ребят, а что вы вообще под mvc то понимаете? присутствие структуры с названием Controller?

у него там в примере вполне себе MVC, и контроллер, и модель, и вьюха - все на месте

у него там в примере вполне себе MVC, и контроллер, и модель, и вьюха - все на месте

ну ты понимаешь, что контроллер - это http handler, модель - бизнес-слой, а вьюха - response?

ты как-то по другому свои гошечки делаешь?

ну ты понимаешь, что контроллер - это http handler, модель - бизнес-слой, а вьюха - response?

посмотри сам, что там в примере https://pastebin.com/n85sF8hK

я смотрел

ты как-то по другому свои гошечки делаешь?

естественно иначе.

у меня _вообще_ нет ассоциации с mvc

ассоциации нет, а mvc есть

в mvc http request приходит в точку входа, называемую в контексте парадигмы controller (в go это http handler), дальше запрос идет в модель (это бизнес-слой приложения), а бизнес слой возвращает данные клиенты (view, оно же http response с помощью response writer). В общем-то парадигме mvc следует большинство веб (и не только) приложений, в т.ч. и на го.

а вот что ты хотел сказать: зачем ты тащишь mvc как в php? выкинь, и делай в go style

ассоциации нет, а mvc есть

s/mvc/Європа лол

в mvc http request приходит в точку входа, называемую в контексте парадигмы controller (в go это http handler), дальше запрос идет в модель (это бизнес-слой приложения), а бизнес слой возвращает данные клиенты (view, оно же http response с помощью response writer). В общем-то парадигме mvc следует большинство веб (и не только) приложений, в т.ч. и на го.

О, чувак, you with me

не, не надо. я просто за точность формулировок

а вот что ты хотел сказать: зачем ты тащишь mvc как в php? выкинь, и делай в go style

вот хотя бы так

это да. даже на пхп уже от контроллеров уходят, юзая похожие на go http handler'ы

неменого не понимаю.В чём отличие хендлера от контроллера?

в контексте mvc ни в чем

хэндлер это и есть контроллер mvc

это да. даже на пхп уже от контроллеров уходят, юзая похожие на go http handler'ы

а зачем тогда они уходят

но тут речь зашла про контроллер как его делали в пхп - то есть несколько экшнов в одном классе

типа логически объединенные экшны

ааа

в общем есть контроллер как понятие mvc, а есть реализации в различных языках - handler в go, контроллер с экшнами в php итд

по-моему начинаю понимать, спасибо)

а в чём проблема контроллеров как класса

я раньше на рельсах писал

вполне себе норм было

а зачем? почему не использовтаь отдельные экшны/хэндлеры?

ну наверно типо можно в одном месте собирать специфичный для данной rest сущности код

всякие обработчики параматров и тп

ну наверно типо можно в одном месте собирать специфичный для данной rest сущности код

да, в каком нибудь PostResourceЧегоНибудь

ну типо да) Но для обычных сайтов, интернет магазинов, соц сетей и тп, вроде самое-то для всего остального не знаю

ну типо да) Но для обычных сайтов, интернет магазинов, соц сетей и тп, вроде самое-то для всего остального не знаю

эм. ты в какую-то другую степь пошел. все сайты в общем-то обычные.

Мля, я только сейчас допер о чем вы. В асп.нете, к примеру, логика работы с юзерами организовывалась в UsersController, в котором были экшены Register, Login, RestorePassword, AnotherHrenoten

Я совсем не о тех контроллерах говорил, а о том, что подразумевалось в понимании экшнн

я о том говорю: экшн = хэндлер

эм. ты в какую-то другую степь пошел. все сайты в общем-то обычные.

обычные сайты имел в виду где рест работает. Просто на хабре пару раз встречал жалобы, что у них рест плохо работает. И в паре книг читал про это.

народ, меня тут подзадолбала ширина контента гитхаба на 20" экране, поэтому вот https://userstyles.org/styles/153877/full-width-github

Народ, а вот помогите решить концептуальный вопрос: есть 5-6 утилиток командной строки у которых есть какой то набор flag параметров которые могут подгружаться из Yaml Конфига набор параметров в чем то совпадает в чем то расходится плюс хочется иметь возможность любой параметр сконфигурировать через переменные окружения поглядел awesome-go в буду юзать https://github.com/spf13/viper https://github.com/spf13/сobra НО хочу сделать какой то базовый пакет должен быть reusable код который инициализируется для общих параметров и потом раскидывается в какую то структуру структура имеет базовый тип в этом базовом пакете и наследуемые структуры уже в утилитках не понимаю как организовать код чтобы не было кучи копипаста в каждой из утилиток

привет, друзья! а есть спецы по DDD в чатике?

есть

Такое ощущение, что бест практис и запреты это просто решение какого-то человека или группы основанное чисто на своём мнении

Идёшь в один язык, там топят за одно

Такое ощущение, что бест практис и запреты это просто решение какого-то человека или группы основанное чисто на своём мнении

в гошке ровно так и есть

Идёшь в другой, там топят совсем за другое и ругают предыдущих

в гошке ровно так и есть

Так и понял))

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

Почему нельзя было ввести какие-нибудь специальные макросы

Или препроцессорный язык

Или препроцессорный язык

Или дж******и?

Или дж******и?

Или дже****ки))

Или дж******и?

опасные слова )

Или препроцессорный язык

Тогда будет по скорости компилироваться как сишка и вообще не поддаваться статическому анализу.

Тогда будет по скорости компилироваться как сишка и вообще не поддаваться статическому анализу.

Имел в виду для кодогенерации. В го многие старые вещи по новому сделаны, почему бы не взглянуть и здесь с новой стороны

Имел в виду для кодогенерации. В го многие старые вещи по новому сделаны, почему бы не взглянуть и здесь с новой стороны

Офигенно же придумано. Сгенерировал код - тут тебе и интелисенс, анализ, вся херня. А так в случае с макросами все будет раскрываться только во время компиляции

Имел в виду для кодогенерации. В го многие старые вещи по новому сделаны, почему бы не взглянуть и здесь с новой стороны

Есть мнение, что нужно наоборот делать всё традиционно. Например, форматирование дат.

Офигенно же придумано. Сгенерировал код - тут тебе и интелисенс, анализ, вся херня. А так в случае с макросами все будет раскрываться только во время компиляции

С этим согласен. Я про то, что выглядит это все немного кустарно

С этим согласен. Я про то, что выглядит это все немного кустарно

Зато все просто, как палка

1. Та мвц понятное дело не катить на бекенде с рестом, тем более на го. Я просто раньше кормился будучи разработчиком на дотнете. Когда хтмл рендерили на сервере, поступал запрос, он обрабатывался. Формировался респонс и передавался шаблонизатору, который генерил страницу на основе ViewModel. Сейчас страницы на сервере генерят только пхпшники. 2. Ну блин, можно назвать не контроллер, а "экшн" или "РеквестПроцессор" какой-то 3. К сожалению, когда мы получаем информацию о типе, в го нет конструкторов, потому эти значения можно получить только лишь экспортируя экземляр типа через переменную пакета, либо придумывать свои инициализаторы. 4. Та похер на те бенчмарки. 99% обработки запроса занимает IO, а не парсинг хттп-запроса

То есть фронт должен генерить хтмл шаблон?

То есть фронт должен генерить хтмл шаблон?

В смысле, а где еще, может на пхп, что ли?

В смысле, а где еще, может на пхп, что ли?

Вот кстати, а если фронт тормозит? То есть бэкенд отрабатывает быстрее чем фронт рендерит шаблон.

Может рендерить на сервере таки?

Вот кстати, а если фронт тормозит? То есть бэкенд отрабатывает быстрее чем фронт рендерит шаблон.

И что потом?

Всё.

Получил запрос, отработал, отрендерил шаблон, отдал.

Стоит только формочку добавить и все, лол

Никуа не лол.

127.0.0.1:80/login 127.0.0.1:80/sign 127.0.0.1:80/list

javascript шлёт ансихрон на бэкенд, бэкенд отдаёт json к примеру.

javascript шлёт ансихрон на бэкенд, бэкенд отдаёт json к примеру.

Асинхрон?

Асинхрон?

А как по другому?

Без асинхронности вся страница колом станет.

Люди, подскажите, как выглядит распространённая практика размазывания кода по файлам. Будет много пакетов, хотелось бы как-то структурировать. К примеру, где хранить интерфейсы, структуры, методы?