Емкаа
the worst thing about prison was the dementors.
- Член од
- 14 мај 2008
- Мислења
- 5.154
- Поени од реакции
- 13.272
Ахам, а што е тоа асинхроно извршување?Се збори за воведување на такви риквести и во ПХП, ама само се збори.
Pls ова нека е сарказам.
Follow along with the video below to see how to install our site as a web app on your home screen.
Забелешка: This feature may not be available in some browsers.
Ахам, а што е тоа асинхроно извршување?Се збори за воведување на такви риквести и во ПХП, ама само се збори.
Што е проблемот со тоа?Pls ова нека е сарказам.
Јава и тоа Јава ЕЕ 7+ (не Spring), но нема да згрешиш и со .НЕТ, само мене повеќе ми лежи Јава. PHP ретко кој работи, ама она core, повеќе е Џомла, WordPress и други платформи за да се склопи некој сајт набрзина.

ја работам
https://personalprogrammer.mk/job-offers/
нема многу луѓе али понуди за работа имаш и не само вордпрес, друпал и џумла туку баш работа у MVC архитектури.
А plain php можеш и во вордпрес да користиш, не гледам што е проблемот.
MVC е архитектурен патерн и во тој контекст го нареков архитектура.Морав да те цитирам пошо пред некое време дискутирав со колеги на оваа тема.
Се почесто слушам како некој изработил проект со 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 лејер архитектура кај што би имала персистенс лејер, домеин или сервис лејер и презентејшн лејер.
Многу поделени мислења имам слушнато околу ова и навистина ме интересира мислење на повеќе луѓе.
Мое мислење е дека е патерн за организирање на презентациски слој. Доколку голем број од code base - от се наоѓа во овој слој некако и би можеле да ја сметаме за архитектурен патерн, меѓутоа и тогаш тоа би било само во рамки на UI слојот.
Ај да се разбереме, во MVC не можеш да имаш separation of concerns пошто ниту моделот, ниту контролерот, ниту вјуто имаат главен concern да хендлаат бизнис логика. Ниту постои некое пишано правило дека контролерот е тој што треба да ти ја хендла бизнис логиката. Не за џабе се вика контролер, менаџер класа е. Сфати го ко сообраќаец на раскрсница кој дава знаци кој кај треба да иде, и ама воопшто не треба да му биде грижа за биснис логиката, со тоа што ставаш бизнис логика во контролерот го нарушуваш single responsibility principle од SOLID принципите. Што му е грижа на контролерот? Во зависност од тоа што параметри имаш во гет риквестот кој контролер, поточно кој метод од контролер класата да ти го ранува, за во тој метод да ти се инстанцира соодветен модел, преку чија инстанца ќе повикуваш други методи кои ќе земаат податоци од база, податоци кои ќе му ги дадеш на некој лоад вју метод во истиот метод на контролер класата(кој на лоад вју методот може да му пристапи пошто го екстендува основниот контролер кај што е дефиниран тој лоад вју метод) кој потоа ќе му ги предаде податоците на вјуто (ова ми е најпросто што можев да објаснам). Ако сакаш да имаш separation of concerns ќе си креираш посебна класа која што ќе ти ја хендла бизнис логиката, а додека контролерот у конструкторот ќе ја прима инстанцата на таа сервис класа и таа инстанца ќе му ги предаде податоците во бараната форма на контролерот.И јас мислам дека контролерот треба да ја хендла бизнис логиката. И во MVP е исто, view-то е dummy и само реагира на инпут од корисник или од презентерот ( контролерот ). Презентерот е тој кој ја хендла цела логика. Моделот ги обезбедува податоците. Што се случува доколку податоците ги добивате од некој надворешен сервис и од база?
За мали апликации јас би одела со слоевита архитектура, со тоа што mvc би го употребила во презентацискиот слој. Моделот би бил абстрактен и сите информации би ги добивал од слојот под презентацискиот.
Вака колку толку имаш некој separation of concerns и немаш толку тесна поврзаност на компонентите.
Ај да се разбереме, во MVC не можеш да имаш separation of concerns пошто ниту моделот, ниту контролерот, ниту вјуто имаат главен concern да хендлаат бизнис логика. Ниту постои некое пишано правило дека контролерот е тој што треба да ти ја хендла бизнис логиката. Не за џабе се вика контролер, менаџер класа е. Сфати го ко сообраќаец на раскрсница кој дава знаци кој кај треба да иде, и ама воопшто не треба да му биде грижа за биснис логиката, со тоа што ставаш бизнис логика во контролерот го нарушуваш single responsibility principle од SOLID принципите. Што му е грижа на контролерот? Во зависност од тоа што параметри имаш во гет риквестот кој контролер, поточно кој метод од контролер класата да ти го ранува, за во тој метод да ти се инстанцира соодветен модел, преку чија инстанца ќе повикуваш други методи кои ќе земаат податоци од база, податоци кои ќе му ги дадеш на некој лоад вју метод во истиот метод на контролер класата(кој на лоад вју методот може да му пристапи пошто го екстендува основниот контролер кај што е дефиниран тој лоад вју метод) кој потоа ќе му ги предаде податоците на вјуто (ова ми е најпросто што можев да објаснам). Ако сакаш да имаш separation of concerns ќе си креираш посебна класа која што ќе ти ја хендла бизнис логиката, а додека контролерот у конструкторот ќе ја прима инстанцата на таа сервис класа и таа инстанца ќе му ги предаде податоците во бараната форма на контролерот.
Епа тоа ми е муабетот цело време. Дека MVC не е архитектурен патерн, туку патерн за приказ на UI делот. ОСВЕН во случаи во кои самиот проект дозволува примена на MVC на архитектурно ниво ( basic crud апликации ). Во тој случај мислам дека и би било прифатливо "бизнис логиката" да биде сместена во контролерот или моделот, сеедно.
За секој друг покомплексен проект примената на MVC на ниво на глобална архитектура доведува до тесна поврзаност на компонентите и никаква можност за промена на view-то .
@teneke самото име Model - View - Controller мислам дека е само по себе дескриптивно.
