Именно для борьбы такого плана и придумываются методологии типа TDD, BDD
Придуманы интерфейсы и принципы ООП
Придуманы паттерны (в частности: адаптер, декоратор и прокси)
Кратко -- придумываете интерфейс, придумываете клиентский код
а далее реализуете различный код, но каждый раз он наружу торчит на языке вашего бизнеса
У нас паршивое высшее было (политен ДВГТУ)... я учился на отлично не напрягаясь, ушел чуть по другим причинам после 3 курса -- работал на 2 работах и амурные дела :)
Ощущение противоречивое, качество и уровень -- донное днище, думать учил только сопроматчик и все, остальные несли больше вреда, чем пользы -- платная сдача, наплевательство, отнимает время (например на проезд до корпуса от общежития нужно было мне ездить по 1-2 часа в одну сторону), просто неадекватные -- все это деморализует, разочаровывает и как минимум -- не дает НИЧЕГО!
Затык только в дипломе, гребаная бумажка, ничего общества не имеющая с адекватностью, знание не стоит вообще с ней ассоциировать
Покупает заказчик Делаете экспертизу (например одобряете или бракуете выбор) или вообще наводите на нужный, за заказчиком только оформить остаетсяДополнительное обслуживание уже делаете отдельной услугой
Покупаете вы
Делаете договор, размещаете его на своем хостинге, тут можете накрутить цену на сам хостинг (если есть лояльное отношение к вам).
Продаете допуслуги, какие предлагают сами компании хостинга
Как понимаете -- ЛЮБОЙ вариант можно осуществить, любой можно реализовать выгодно всем... все от доверия и от ваших предложений зависит
Много не нужно, тк это тема с опытом приходит, то есть паттерны решают некие проблемы, с которыми рано или поздно столкнетесь (или не столкнетесь)
Собеседующие обычно просто спрашивают знание, без реализации
в данном коде идет просто обработка запроса и добавление строки (сссылки) к товару в БД
а скачивание происходит в момент ресайза, когда идет запрос картинки из БД и когда ее нет локально -- запрашивается картинка по ссылке, грузится в оригиналы и ресайзится уже
затык как раз на скачивании происходит
вам в файл api/Image.php в метод resize(), а еще точнее в метод download_image()
Любую можно сделать хорошо, если будет достойный контент -- люди освоят ваш способ оценки и адаптируют свой паттерн поведения под него
Первично -- контент
Правильно ли я понял, что всё это добро делается в одном методе и сам запрос модифицируется через параметр передаваемый в selectAll(). То есть selectAll() выведет весь массив. selectAll(30,30) выведет с ограничением.
select all, но не всегда, иногда не all, а только 30 :)
Зелимхан Бельтоев, нет никакой связи между нагрузкой и уровнем ВУЗа
могу гонять в низком и дать фристайл в сильном, и то от преподавателя к преподавателю
И еще немного смущает, что это может нарушить концепцию "тонкого контроллера".
Потому что я отметил важный момент -- модель -- это целый слой, а не только сущности
валидация, работа сущностей друг с другом -- все это тоже относится к вашему бизнесу, просто проверка купюры не относится к пополнению баланса или приходу, она стоит "где-то выше"
потому сейчас везде в интернете и говорят про сервисный слой, некая абстракция, которая работает с сущностями,
контроллер всего лишь готовит очищенные данные, вызывает нужный сервис и все -- тоньше и не придумать
Придуманы интерфейсы и принципы ООП
Придуманы паттерны (в частности: адаптер, декоратор и прокси)
Кратко -- придумываете интерфейс, придумываете клиентский код
а далее реализуете различный код, но каждый раз он наружу торчит на языке вашего бизнеса