Георг Гаал, А почему вопрос? Потому что сложно контейнерами управлять и масштабировать их? У нас сейчас на дев сервере проект на docker compose работать и пока все очень стабильно, никаких проблем нет
Ну это всегда вроде понятно.. Однако геттеры имеют этот префикс. То есть всегда по сути когда имя метода - существительное, то и так ясно, что оно возвращает данные, а не обрабатывает их. И префикс get всегда и добавляется к существительным. getPrice, getTax, getFirstItem..
Интересно просто, когда они пишут код, как они мыслят. Такое ощущение, что они кидают монетку и решают использовать в этом классе или методе префикс или нет.
Классически считается что название функции должно представлять глагол
Как мы видим, в тех примерах, которые я привел как раз это правило не выполняется. Метод first, all в коллекции это не глагол, tax в корзине тоже не глагол. И это нарушение кажется почему то вполне привлекательным и удобным, так как getFirst, getAll (getItems), getTax кажется слишком исчерпывающим и лишним. Может это глупое правило, которому я тоже привык следовать, приписывая всюду get, чтобы метод превратился в глагол?
JhaoDa, Во-первых, не строй из себя умника ладно? Ты попадаешь под пункт 5.16, если что со своими глупыми комментариями. Во-вторых, я описал, почему я поставил эти теги, а ты видимо даже не читал вопроса. Мне интересно мнение спецов из разных фреймворков, так как стандартны именования у разработчиков симфони допустим более строгие и мнение у них будет другое по этому вопросу. В-третьих, пусть модератор решает насколько корректны тут теги, а не ты и в случае чего принимает действия.
тяжко тебе будет...
Про это вообще молчу.. Тебе тяжко, я живу не напрягаясь, а ты свою жизнь можешь делать какой захочешь, так что тяжко думаю тебе
Есть не гайды, а куча книг на тему проектирования ПО. Можно просто их читать и пытаться понять, а потом, что самое главное применять это в своих проектах. Но а вообще на самом деле, пока не столкнется сам с проблемами плохого проектирования и сам не почувствуешь боль от них, настоящее понимание не придет. Так что самое главное это опыт
Дмитрий, смотри, этот интерфейс ты откуда то скопировал верно? https://github.com/drmvc/orm/blob/master/src/Orm/I... Тупо скопировал и даже не понял зачем это сделал.. Мы просто подошли к тому, что написав свой говно фреймворк ты ничему не научился, про что я и говорил
Дмитрий, блин вот ты странный.. Главное при разработки такого фреймворка это получить как можно больше опыта и научиться чему то. То что ты сделал это не функция ещё раз тебе повторяю, а зависимость на конкретной реализации, отсутствие контракта между классами, ясненько? Это не функция, а не понимание основ просто. Вот у тебя есть интерфейс билдера, опять же ты понимаешь, что в нем нет никакого смысла (объясни, зачем ты его сделал, чтобы был? Ты не используешь его возможностей), так как и билдера у тебя встроен тупо в класс Orm? Почитай про DI, может до тебя дойдет
Дмитрий, речь о том, что вы как в танке не хотите ни к кому прислушиваться. Никто вообще не хотел вести эту бессмысленную дискуссию о фреймворках, о чем я сказал в самом начале. Симфони я указал лишь в качестве примера, на который можно равняться (лучшим я его назвал в том смысле, что он самый популярный и качественный однововременно, а его компоненты полностью независимы и используются многими другими фреймворками). На ваше решение равняться нельзя, просто хотя бы потому, что им пользуются и разрабатывает 2 человека. То, что вы говорите, что я прикопался - это вообще очень глупо, так как я пользователь вашего фреймворка, а не вы и я сразу же нашел причину, по которой ваша орм бракуется и не может использоваться в продакшене, так как она привязана к конкретной реализации, что является достаточно большой проблемой и недостатком. И я просто не стал дальше смотреть, просто этим я хотел сказать, что делая свой фреймворк опыта особо не получишь. Вот если бы вы заглянули в другие орм например и посмотрели как там, я думаю это многое прояснило бы и пользы было бы гораздо больше. Это нормально, что человек не понимает иногда каких то проблем в своих решениях, но рост происходит тогда, когда ты смотришь на свое решение и понимаешь, что оно гавно. А если тебе полностью нравится твой код, написанный год назад, скорее всего с ним что то не так
Дмитрий, еще раз объясняю. https://github.com/drmvc/orm/blob/master/src/Orm/O... Вот есть такой код. Неужели не видно, в чем тут проблема? Во-первых, мало того, что этот метод не может знать, что у entity есть свойство id, так это даже нигде не определяется. Если в моей таблице вместо поля id было бы другое или вообще его небыло, этот метод крашнулся бы.
Дмитрий, да магия то магией. Магией пусть клиент пользуется. Orm класс же должен зависеть от интерфейса. Как минимум поле для id в таком случае этот интерфейс должен отдавать.
Дмитрий, простейший способ улучшить ситуацию сделать интерфейс для entity и в нем метод getIdField например, так как сейчас класс orm не может знать, что у entity вообще есть поле id
Дмитрий, ну орм не должна определять какой тип id у меня будет, в том то и дело, что ты за меня решил, чтт у меня инкремент будет. Почему это ид у меня только числом может быть? Я помню промучился с таким пакетом, который тоже возомнил, что айдишник должен быть именно числом. У меня же айдишником был хэш (строка). Также идёт четкая пиивязка к полю id, это поле правильней было бы брать из свойства entity. У меня допустим не id, а uuid. Получается заюзать метод saveEntity я не смогу.
