Од какви програмери(back-end) имаат потреба нашите компании?

[Емкаа]

Ахам, а што е тоа асинхроно извршување? Се збори за воведување на такви риквести и во ПХП, ама само се збори.

Pls ова нека е сарказам.

 

[zmej gorjanin]

Pls ова нека е сарказам.

Што е проблемот со тоа?

 

[Amaterasu]

Касно се уклучувам на темава, но се надевам дека вие што работите JS на backend ќе можете да ми одговорите. Зошто мислите дека JS е подобра за backend од .NET или пак Java (Spring) ? Кои се предностите според вас во развојниот процес, и дали при развојот користите чист јаваскрипт или пак користите TypeScript и други технологии ?

 

[july541]

Јава и тоа Јава ЕЕ 7+ (не Spring), но нема да згрешиш и со .НЕТ, само мене повеќе ми лежи Јава. PHP ретко кој работи, ама она core, повеќе е Џомла, WordPress и други платформи за да се склопи некој сајт набрзина.

 

[zmej gorjanin]

Јава и тоа Јава ЕЕ 7+ (не Spring), но нема да згрешиш и со .НЕТ, само мене повеќе ми лежи Јава. PHP ретко кој работи, ама она core, повеќе е Џомла, WordPress и други платформи за да се склопи некој сајт набрзина.

ја работам

https://personalprogrammer.mk/job-offers/

нема многу луѓе али понуди за работа имаш и не само вордпрес, друпал и џумла туку баш работа у MVC архитектури.

А plain php можеш и во вордпрес да користиш, не гледам што е проблемот.

 

[Емкаа]

ја работам

https://personalprogrammer.mk/job-offers/

нема многу луѓе али понуди за работа имаш и не само вордпрес, друпал и џумла туку баш работа у MVC архитектури.

А plain php можеш и во вордпрес да користиш, не гледам што е проблемот.

Морав да те цитирам пошо пред некое време дискутирав со колеги на оваа тема.
Се почесто слушам како некој изработил проект со MVC архитектура. MVC e патерн за организирање на презентациски слој, а не архитектура.

 

[zmej gorjanin]

Морав да те цитирам пошо пред некое време дискутирав со колеги на оваа тема.
Се почесто слушам како некој изработил проект со MVC архитектура. MVC e патерн за организирање на презентациски слој, а не архитектура.

MVC е архитектурен патерн и во тој контекст го нареков архитектура.

https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013

Model–view–controller (MVC) is an architectural pattern commonly used for developing user interfaces that divides an application into three interconnected parts. This is done to separate internal representations of information from the ways information is presented to and accepted from the user.[1][2] The MVC design pattern decouples these major components allowing for efficient code reuse and parallel development.

Особено е популарен во PHP заедницата преку веб фрејморците ко Ларавел и Кодигнајтер кај што аут оф да бокс добијаш MVC што не значи и дека си обврзана да користиш тоа што добиваш аут оф да бокс. Со примена на репозитори патерн можеш лесно да креираш мулти лејер или 3 лејер архитектура кај што би имала персистенс лејер, домеин или сервис лејер и презентејшн лејер.

 

[Емкаа]

MVC е архитектурен патерн и во тој контекст го нареков архитектура.

https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013

Model–view–controller (MVC) is an architectural pattern commonly used for developing user interfaces that divides an application into three interconnected parts. This is done to separate internal representations of information from the ways information is presented to and accepted from the user.[1][2] The MVC design pattern decouples these major components allowing for efficient code reuse and parallel development.

Особено е популарен во PHP заедницата преку веб фрејморците ко Ларавел и Кодигнајтер кај што аут оф да бокс добијаш MVC што не значи и дека си обврзана да користиш тоа што добиваш аут оф да бокс. Со примена на репозитори патерн можеш лесно да креираш мулти лејер или 3 лејер архитектура кај што би имала персистенс лејер, домеин или сервис лејер и презентејшн лејер.

Многу поделени мислења имам слушнато околу ова и навистина ме интересира мислење на повеќе луѓе.
Мое мислење е дека е патерн за организирање на презентациски слој. Доколку голем број од code base - от се наоѓа во овој слој некако и би можеле да ја сметаме за архитектурен патерн, меѓутоа и тогаш тоа би било само во рамки на UI слојот.

 

[zmej gorjanin]

Многу поделени мислења имам слушнато околу ова и навистина ме интересира мислење на повеќе луѓе.
Мое мислење е дека е патерн за организирање на презентациски слој. Доколку голем број од code base - от се наоѓа во овој слој некако и би можеле да ја сметаме за архитектурен патерн, меѓутоа и тогаш тоа би било само во рамки на UI слојот.

Разбирам зошто не сметаш дека е архитектура. Нема separation of concerns. Според некоја дефиниција вјуто е пресентејшн лејер, моделот комуницира со база и се грижи за бизнис логиката (тука настанува проблемот, со дебелите модели) и контролерот само пренасочува податоци од моделот до вјуто. Иако ако мене ме прашуваш од практично искуство, многу почесто се среќавам со тоа да бизнис логиката стои во контролерот, покрај тоа што го хендла јузер инпутот и пренасочува податоци до вјуто.

 

[LepiDzoni]

Controllerot vo MVC otsekogas tradicionalno imal uloga vo menadziranje na biznis logika i user input, koordinacija pomegju modelot i view itn
logikata sto ja drzi modelot najcesto se odnesuva na menadziranje na tabeli od bazata, kako na primer fenomenalniot active record na rails, a prasanjeto kade gi isprakja podatocite od bazata ne go interesira mnogu, on treba samo da gi "publish"ne za kontrolerot da gi primi. MVC paternot e inspiriran od klasicniot publish/subscribe sistem na observer pattern od gof.

 

[Емкаа]

И јас мислам дека контролерот треба да ја хендла бизнис логиката. И во MVP е исто, view-то е dummy и само реагира на инпут од корисник или од презентерот ( контролерот ). Презентерот е тој кој ја хендла цела логика. Моделот ги обезбедува податоците. Што се случува доколку податоците ги добивате од некој надворешен сервис и од база?
За мали апликации јас би одела со слоевита архитектура, со тоа што mvc би го употребила во презентацискиот слој. Моделот би бил абстрактен и сите информации би ги добивал од слојот под презентацискиот.
Вака колку толку имаш некој separation of concerns и немаш толку тесна поврзаност на компонентите.

 

[zmej gorjanin]

И јас мислам дека контролерот треба да ја хендла бизнис логиката. И во MVP е исто, view-то е dummy и само реагира на инпут од корисник или од презентерот ( контролерот ). Презентерот е тој кој ја хендла цела логика. Моделот ги обезбедува податоците. Што се случува доколку податоците ги добивате од некој надворешен сервис и од база?
За мали апликации јас би одела со слоевита архитектура, со тоа што mvc би го употребила во презентацискиот слој. Моделот би бил абстрактен и сите информации би ги добивал од слојот под презентацискиот.
Вака колку толку имаш некој separation of concerns и немаш толку тесна поврзаност на компонентите.

Ај да се разбереме, во MVC не можеш да имаш separation of concerns пошто ниту моделот, ниту контролерот, ниту вјуто имаат главен concern да хендлаат бизнис логика. Ниту постои некое пишано правило дека контролерот е тој што треба да ти ја хендла бизнис логиката. Не за џабе се вика контролер, менаџер класа е. Сфати го ко сообраќаец на раскрсница кој дава знаци кој кај треба да иде, и ама воопшто не треба да му биде грижа за биснис логиката, со тоа што ставаш бизнис логика во контролерот го нарушуваш single responsibility principle од SOLID принципите. Што му е грижа на контролерот? Во зависност од тоа што параметри имаш во гет риквестот кој контролер, поточно кој метод од контролер класата да ти го ранува, за во тој метод да ти се инстанцира соодветен модел, преку чија инстанца ќе повикуваш други методи кои ќе земаат податоци од база, податоци кои ќе му ги дадеш на некој лоад вју метод во истиот метод на контролер класата(кој на лоад вју методот може да му пристапи пошто го екстендува основниот контролер кај што е дефиниран тој лоад вју метод) кој потоа ќе му ги предаде податоците на вјуто (ова ми е најпросто што можев да објаснам). Ако сакаш да имаш separation of concerns ќе си креираш посебна класа која што ќе ти ја хендла бизнис логиката, а додека контролерот у конструкторот ќе ја прима инстанцата на таа сервис класа и таа инстанца ќе му ги предаде податоците во бараната форма на контролерот.

 

[teneke]

MVC е патерн за мене, употребен во некоја конкретна архитектура, но не гледам како може да биде презентациски слој, нема логика.

 

[Емкаа]

Ај да се разбереме, во MVC не можеш да имаш separation of concerns пошто ниту моделот, ниту контролерот, ниту вјуто имаат главен concern да хендлаат бизнис логика. Ниту постои некое пишано правило дека контролерот е тој што треба да ти ја хендла бизнис логиката. Не за џабе се вика контролер, менаџер класа е. Сфати го ко сообраќаец на раскрсница кој дава знаци кој кај треба да иде, и ама воопшто не треба да му биде грижа за биснис логиката, со тоа што ставаш бизнис логика во контролерот го нарушуваш single responsibility principle од SOLID принципите. Што му е грижа на контролерот? Во зависност од тоа што параметри имаш во гет риквестот кој контролер, поточно кој метод од контролер класата да ти го ранува, за во тој метод да ти се инстанцира соодветен модел, преку чија инстанца ќе повикуваш други методи кои ќе земаат податоци од база, податоци кои ќе му ги дадеш на некој лоад вју метод во истиот метод на контролер класата(кој на лоад вју методот може да му пристапи пошто го екстендува основниот контролер кај што е дефиниран тој лоад вју метод) кој потоа ќе му ги предаде податоците на вјуто (ова ми е најпросто што можев да објаснам). Ако сакаш да имаш separation of concerns ќе си креираш посебна класа која што ќе ти ја хендла бизнис логиката, а додека контролерот у конструкторот ќе ја прима инстанцата на таа сервис класа и таа инстанца ќе му ги предаде податоците во бараната форма на контролерот.

Епа тоа ми е муабетот цело време. Дека MVC не е архитектурен патерн, туку патерн за приказ на UI делот. ОСВЕН во случаи во кои самиот проект дозволува примена на MVC на архитектурно ниво ( basic crud апликации ). Во тој случај мислам дека и би било прифатливо "бизнис логиката" да биде сместена во контролерот или моделот, сеедно.
За секој друг покомплексен проект примената на MVC на ниво на глобална архитектура доведува до тесна поврзаност на компонентите и никаква можност за промена на view-то .
@teneke самото име Model - View - Controller мислам дека е само по себе дескриптивно.

 

[teneke]

Епа тоа ми е муабетот цело време. Дека MVC не е архитектурен патерн, туку патерн за приказ на UI делот. ОСВЕН во случаи во кои самиот проект дозволува примена на MVC на архитектурно ниво ( basic crud апликации ). Во тој случај мислам дека и би било прифатливо "бизнис логиката" да биде сместена во контролерот или моделот, сеедно.
За секој друг покомплексен проект примената на MVC на ниво на глобална архитектура доведува до тесна поврзаност на компонентите и никаква можност за промена на view-то .
@teneke самото име Model - View - Controller мислам дека е само по себе дескриптивно.

Да така е, не е архитектура MVC, туку патерн кој можеш да го искористиш во повеќе видови на архитектура за полесно организирање на UI кодот.