Вопрос по тестовому

Тут могли просто придраться к оформлению кода.
https://www.php-fig.org/psr/psr-0/
https://www.php-fig.org/psr/psr-1/
https://www.php-fig.org/psr/psr-2/
https://www.php-fig.org/psr/psr-3/
https://www.php-fig.org/psr/psr-4/
Все зависит от самого работодателя

 

@Dron-Boy, тестовое задание такое и было как вы написали или имело чёткую формулировку ТЗ ?

 

хм... тогда не знаю просто у вас ни MVC ни ООП в коде нет (хотя и есть попытка их использовать), но в ТЗ про них тоже ничего не указано. Ну если только к запросам в цикле претензия, зло которое ни к mvc ни к объектам отношения не имеет, но тут как бы разовая операция и можно немного сачконуть. Другое дело, что ситуацию надо объяснить и обосновать работодателю, из каких зол надо выбирать меньшее.

+ вижу сортировку, но не вижу фильтрации по вендорам

 

Ну, тогда и я добавлю про логику. Если говорить об MVC, то бизнес-логика должна быть в модели, а не в контроллере. У Вас парсинг в контроллере, а то что в модели назвали парсингом - сохранение в БД.

 

про MVC вам уже сказали, там мухи с котлетами, а про ООП назовите хотя бы один шаблон проектирования который вы применили в коде?

 

например вот это

PHP:

1.         public function getData(){
2.             $order = "ASC";
3.             if(isset($_GET['order'])){
4.                 $order = ($_GET['order'] == 1 ? "DESC" : 'ASC');
5.             }          
6.             $sth = $this->connect()->prepare("SELECT * FROM product LEFT JOIN category ON (product.cat_id=category.id) ORDER BY product.vendor $order");
7.             $sth->execute();
8.             $result = $sth->fetchAll(PDO::FETCH_ASSOC);
9.             return $result;
10.         }

 

@Dron-Boy, ну подключение к БД обычно синглтон, а товар - это обычно объект, раз много товаров, то должна быть фабрика и тд.

 

@Dron-Boy контроллер этот как пульт от телевизора, в нём не должно быть толком никаких манипуляций, только запуск методов из модели.

 

@Dron-Boy, В качестве примера, можно было бы в модели создать свой объект товара и пару оберток для него - вывод на страницу и сохранение в БД. Этот паттерн называется "Декоратор"
Про фабрику Вам уже написали.

 

@Dron-Boy Контроллер

PHP:

1.   $image = $request->file('image');
2.      
3.       $description = $request->input('description');
4.      
5.       $this->imageClass->add($image, $description);
6.  
7.       $this->imageClass->save();
8.  
9.       $idNewImage = $this->imageClass->id;
10.       $categories = $request->input('choose-category');
11.      
12.       $relation = \App\Services\Image::find($idNewImage);
13.        
14.       $relation->categories()->attach($categories);
15.          
16.       return redirect('/');

Модель

PHP:

1. public function add($image, $description)
2.     {
3.         $fileName = $image->store('uploads');
4.         $this->image = $fileName;
5.         $this->description = $description;
6.         $this->id_user = Auth::id();
7.     }

--- Добавлено ---

Нет, в моделе не обязательно должно быть только запросы в БД, модель для того, что бы выполнять в ней любые манипуляции с любыми данными (бд, изображения, тексты....), что бы разгрузить контроллер, в контроллер ты заходишь и должен сразу понять, что означает этот код, а за этим контроллером будет стоять модель, в которой вся сложная логика.

Это как нажать нажать на педаль газа, если ты будешь на её жать, ты сразу поймёшь, что она будет делать (это контроллер), а то что твориться под капотом это модель.

 

Контроллер в данном случае получает файл не из модели, а должен передать его на обработку в модель.
Возможно "Строитель" Вам подошел бы лучше фабрики.

 

Вы знаете, в давние времена, когда и php то и не было, а программисты говорили отечественными словами, mvc называли Дакнные->Контроллер->Представление, что в сути обозначает жизненный цикл программы. Мне кажется, это было содранно с концепции REPL в лиспе http://lisper.ru/pcl/lather-rinse-r...те свой разум: Интерактивное программирование, да и в любом подобном программном ядре.
По сути же, иногда встречаются люди, которые свято верят в то, что MVC - это не умозрительная концепция, а прям таки, форма конкретной реализации или, например, (о ужас!) - конкретный программный каркас(фреймворк). Так что, что там имелось в виду - надо спрашивать у тех, кто не одобрил Вашего тестового задания. У меня вот с одной тёткой как-то не заладилась работа, а потом я узнал, что при личной встрече, ей мои уши показались слишком грязные. Она сказала примерно так: "Я сразу догадалась что он плохой специалист, у него уши были грязные". Вот вам и всё собеседование.

 

Предподготовленыйе запросы надо использовать а не имитировать бурную деятельность Юзаете prepare а значение не биндите. Вывод доку читать не умеет или вообще копи-паста.

Примеры из лапки совершенно не уместны.

 

@joshadow, при чём здесь умозрительная концепция? MVC - это способ отделения логики от представления, изменения в одной из этих священных букв ни коим образом не должны влиять на две другие. В итоге приложение может иметь одну модель, три контроллера и пять представлений которые работают одновременно и абсолютно не мешают друг другу.

 

Да... Да... MVC это Данные-Представление-Контроллер. Но, имхо, это обусловлено, способом работы в ВЕБ. Идём на страничку. Для её формирования тянем из разных мест ДАННЫЕ(model - так, как любая база данных,вроде как, есть отражение свойств и взаимодействий части объектов реального мира(модель части реального мира)). На основе данных рисуем интерфейс ПРЕДСТАВЛЕНИЕ. И если нам надо что-то сделать - запускается КОНТРОЛЛЕР, то что производит некие действия. Например подменяет в строчичках кавычки, а потом вызывает методы для отправки их в модель ДАННЫХ. В принципе должна быть одна точка входа у всего проекта. Часто - контроллер, молча, после обработки делает перенаправление на страничку ПРЕДСТАВЛЕНИЯ.
В итоге мы имеем. Файлик с описанием объекта базы данных (model). Его подтягивает рисователь интерфейса (view). И если есть команда на действие - то запускается обработчик(controller), подтягивающий под свои нужды объект базы данных, что-то делает и тихо перенаправляет на рисование интерфейса. Вроде того.
Но как говорил один бородатый человек "Марксизм не догма, а руководство к действию". Я, например, часто леплю контроллер в начале файла, и внутренним флагом сигнала отрисовываю представление. Делаю, (о ужас!) несколько точек входа, для каждой группы задач свою. К примеру - отдельный интерфейс со своей точкой входа для справочника чего-нибудь. Канонически это не верно - но при этом нет необходимости тянуть всё сразу. От этого тока одна скорость исполнения
--- Добавлено ---

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

Да ладно Вам, разве это не родственные вещи REPL и MVC. Этож консольный дедушка и ВЕБ-клиентный сессионный внучёк . Знакомство с дедулей, имхо, открывает путь к пониманию внучка. Говорят, что одним из эффективных методов познания - есть сравнение. Вот я и упомянул его.

 

У меня опечатка и я про ларавел говорил а не про лапку да и не тебе цитировал)

 

Знаете.... причин почему вас могли не взять - масса. Может цветом волос не приглянулись, кто его знает..

Например если бы я принимал прогеров, то я бы вас не взял по причине того, что вы простую задачу решаете сложными методами.

Плюс к этому я не увидел у вас отдельной html страницы на которой был бы реализован вывод данных. (увидел только php-страницу где все это реализовано).

 

А причем здесь роутер? тебе данные дали, и цель конкретного логического кода замутить.
Ко мне в магазин субботу пришел клиент, и место того чтобы спросить это, то то, или вовсе выйти, стал выяснять отношения с своим рабочим прорабом. Мол тот указал где копать яму, а они выкопали совсем где не надо. В итоге обесточили водопровод где - то мини городок. Гейзером бьет и бла бла бла. Саму истеричку пришлось выгнать.
--- Добавлено ---
зачем постоянно добавлять концовку ?> ?
Лично на это смотрю как кодер не вылез с пеленок