diamond: я не согласен с этим грубо говоря, это типичная ошибка. Модель это именно совокупность шаблонов проектирования, а не просто один паттерн или одна абстракция. Я считаю это принцпиальным вопросом, да и если почитать любые источники начиная с момента появления принципа MVC , там именно это и подразумевалось и развивалось. Принципиально иметь отдельно Дата Мэппер который привязан к конкретной реализации БД(или чего еще) и сущности, которая не привязана ни к чему + возможно еще один слой взаимодействия между ними. Таким образом мы получаем достаточно универсальную систему проектирования сложных и не очень систем с гибким подходом к платформе на которой она будет запущена.
diamond: короче. Вопрос был четкий, о "Модели". В простейшем случае это пусть будет твой Репозиторий Хранилище + Маппер. Вот выйдету нас простая модель.
Ну а в целом, я(и не только я) против впаривания паттернов просто так, без понимания необходимости, те пока человек сам не попал в ситуацию когда он решают задачу и начинает делать велосипеды, понимает что здесь нужны различные подходы. Сам по себе сферический в ваккуме любой паттерн вообще не имеет смысла, знаю кучу людей которые в тупую заучивают паттерны, вместо того чтобы сталкиваться с проблемами когда они им понадобятся и тогда придет понимание зачем это так сделано.
Короче патерны нужно не учить, а находить по мере необходимости.
Безусловно помнить о них нужно и важно всегда и это не значит что они там не нужны или про них забыть и придумывать свои велосипеды до посинения. Просто вокруг паттернов столько хайпа поднялось, особенно на собеседованиях часто вопросы в тему и не очень(прежде всего у тех кто сам слабенько технически подкован и спрашивает потому что нужно спросить), вот все и ринулись с головой в зубрежку этих патернов.
diamond: diamond: тут спорный вопрос. В данном конкретном случае это оучень упрощает читабельность целостной структуры кода, для того чтобы понять то, что происходит, да и для всяких утилитарных целей этот подход может быть удобен (к примеру работа с json).
По поводу маппера, то этот шаблон проектирования ОЧЕНЬ часто является частью Модели в MVC. ссылка что ты привел абсолютно этому не противоречит. Подробнее прочитай у человека что нормально все разложил на стаке, что привел в комментарии выше.
dllweb: мне показалось в разделе "ПЕРЕМЕЩЕНИЕ УЗЛА" по последней ссылке как раз то что тебе нуно и расписано, буквально по шагам. Ты накидай себе простенькую БД и сделай все что они делают, там как раз расписано и пошагово и просто в конце объединенный запрос. Так ты проследишь как ключи меняются. Из математики там только необходимость узнать смещение, чтобы обновить все необходимые узлы.
Может если ты по шагам сделаешь на своей простой БД будет понятнее?
Не знаю даже как проще объяснить чем рассказано там.
или вот здесь проиграйся посмотри mjsarfatti.com/sandbox/nestedSortable , нажимай To Array после манипуляций с деревом и смотри как там меняются ключи, вроде бы там идентичный алгоритм используется.
dllweb: долго рассказывать, хотя там все идет по простой логике. Вот тут www.woweb.ru/publ/41-1-0-464 вроде бы четко и понятно расписано. Посмотри, может после этого у тебя уже не будет дополнительных вопросов. Ты главное психологически не делай из этого сложную штуку, как я уже выше отметил этот метод простой и не требует никаких особых математических знаний, в отличии от понимания nested intervals.
John Smith: ну, я говорил совет на основе моего субъективного опыта, мноих отпугивает производительность линукса, а в виртуалке не прочуствуешь насколько может быть комфортна/некомфортна работа. Поэтому я обычно советю людям загрузиться и так поклацать, чтобы на более реальных условиях понять насколько им подходит система, так же сразу будет понятно что из оборудования будет работать из коробки, а что не совсем.
нет, это плохой подход, плодит неопределенное количество null записей, лучше выводить картинки в отдельную таблицу если могут быть, а могут и не быть. Вот если бы картинка была бы обязательным полем то да. А так в моем случае проверка таже происходит на самом деле, только реализация картинок в отдельной таблицы. Мое предложение лучше с точки зрения https://ru.wikipedia.org/wiki/%D0%9D%D0%BE%D1%80%D...
Даврон: роутер тот же комп, так что вторйо вариант искать есть ли для твоего роутера продвинутая прошивка, с дополнительными возможностями. Но опять таки, если слишком просто роутер, то прошивка добавит возможнсотей, но само железо может не потянуть нагрузки, грубо говоря будет тормозить и/или зависать. А старый комп почти всегда дешевле крутого роутера, ему и монитор не нужен, только при первой настройке. А так FreeBSD надежно работает годами, пока само железо не умирает.
вы правы на 100%, это я уже путаюсь в терминах. В любом случае валидация остается частью модели, как ни крути. И конечно же я не настаивал на реализации кода валидации именно в контроллере.
В общем в голове у меня немного закружилось. самое интересное я делаю все как пишет Иван и выходит вобще глупый спор, так что стыдно за глупые высказывания.
Иван я только хотел писать только апдейт, так как по правилам хорошего тона mvc правы вы, но в практике часть валидации модели отрывается от общей бизнес логике и скорее в угоду производительности ФИЗИЧЕСКИ выходит частью контроллера и грубого гвооря и происходят внутри его, до непосредственного начала работы модели. Конечно же тут нужно быть аккуратным и не раздувать сам контроллер, чтобы не было того эффекта что вы написали в виде раздутого контролера.
Тупой уродливый контроллер и проверка ввода в контроллере связана только если для проверки данных в контроллер заходит и бизнес логика. Поэтому правильно так: в общем случае проверка ввода в контроллере, а в частном случае зависит от проекта, точнее модели и бизнес логики, поэтому и может размещена быть в моделе. При этом может быть несколько валидаторов(пример со стаквоерфлоу): ошибка в юзернейме(например можно только латиницу) - валидатор в контроллере, а вот юзернейм уже занят - валидатор в модели.
phpus: на клиенте больше не ради забавы, а скорее для дополнительного удобства пользователя и частичного снижения нагрузки, когда меньше проверок отсылается на сервак.
Ну в модель обычно входит валидация если это часть бизнес логики, в обычном случае это таки работа контроллера. На самом деле валидация бывают и в представлении, когда реализуется при помощи js, но для серьезных дел это не достаточно.
