если критикуете мою реализацию, то делайте в моей теме http://phpforum.su/index.php?showtopic=85296&st=105&hl=. Я с удовольствием раскажу как работает моя, типа ORM.

Я вам написал, что юзают либо ORM, либо хелперы.

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

private function base () {
	$root = $this->input->server('DOCUMENT_ROOT');
	$base = substr(BASE_PATH, strlen($root) - 1);
	
	return rtrim($base, '/');
}

Пока что да.

Метод называется "входные данные", а не вход. :)
Тот класс с этим методом это фабрика которая создает классы для компонента маршрутизации. Входные данные я прописываю а не записываю прям в классе, что бы тестировать потом легче было.

Я собираюсь сделать попроще. К тому же, ORM это громко сказано :D

Вообще то, у него намного гибче чем у меня (с Query Objects), может написать какой угодно запрос а потом положить этот запрос в отдельный объект. Я бы даже сказал это у меня трындец а не у chee. :lol:

_____________
Мой блог

Ясно. Не понятно остается одно - каким боком физические пути относятся к URL...

Вобщем то понятно. "Входные данные" немного иначе преводится, хотя не суть. Вполне читабельно $url->input(). Не без двузначности, но все же.

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

С какой стороны посмотреть. Он решил, что нужно следовать канонам, и все представить объектами. Даже элементарные select запросы.

Я представляю, что бы было с моей системой (рабочую имею ввиду), если бы я юзал эти поделки. Просто не представляю. Но это его выбор, пусть. Он книжек начитался.

В Вашем случае я думаю это не ORM, а обычный хэлпер. Упростить запрсы. Я тоже в эксперементе этим нагрешил, сейчас каюсь. Толку никакого нет.

Но вот в чем беда. Я спокойно юзаю любые литеральные запросы, а в вашем случае два варианта создания сложного запроса:
1. Отказаться от ORM.
2. Отказаться от сложных запросов.

В первом случае вы нарушите принцип ООП
Во втором сделаете приложение примитивным.

Есть третий вариант. Разворачивать свою ORM в сторону SQL синтаксиса, но тогда это обычный дубляж SQL. Да, понятно, что данные теперь будут в виде объектов. Но вот скажите, имеет ли это смысл, если абстрагироваться от ООП?

Никакого смысла нет. Потому я и сказал, это плата за ООП. Чтобы пришли люди и сказали - да. Это чистая парадигма методология. И кто писал, тот крут.

А другие плюсы?

Что касается реализации chee, там еще все печальнее. Если у меня на странице 30 запросов, то будет 30 объектов. Но не суть, даже не берем в расчет память. Сколько обращений к ФС?

Я понимаю, он не считает. Ему важно соблюсти принцип, не отстать от моды. Для нашего эксперимента не столь существенно. Но для реального проекта, я бы ему голову оторвал за эти велосипеды.

chee

Смсл? Вы слились, теперь на общих основаниях. Хотите критиковать - пожалуйста. Не выпрашивайте оценки вашей поделки здесь. Ждите, когда кому станет интересно.

Мне даже не интересно кто "юзают". Ибо они такие же как вы "обыватели". Привыкли мыслить, "как все". Тут вам не здесь. Тут мысли креативные. Пусть вам и не по душе.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.