Agent_J26 ноя 2012 в 15:26

Phalcon: Давайте учиться на примере

9 мин

55K

PHP * Phalcon *

Туториал

Перевод

+27

Комментарии 45

int22h 26 ноя 2012 в 17:51

.....
if ($user->save() == true) 
        {
            echo "Thanks for register!";
        }
....

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

Можно пару слов чем он лучше? В чем его принципиальный интерес?

witdex 26 ноя 2012 в 18:27

Почему не кошерно? Ну возвратила ваша модель false и что дальше, какая это ошибка, что с ней делать?

Agent_J 26 ноя 2012 в 18:55

Всё верно, вывод сообщений должен осуществляться через представления. Работа модели заканчивается на взаимодействии с данными, она не должна знать, каким образам эти данные можно визуализировать.
Собственно здесь $user является моделью, а метод $user->save() лишь возвращает отчёт об операции true или false.

witdex 26 ноя 2012 в 19:34

Неправильно выразился. По тексту int22h понял что возврат текстовых ошибок не должна делать модель а возвращать булево значение, а потом делать проверки заданных значений.
Насчет getMessages знаю, неплохо знаком с фреймворком, неделю назад пересмотрел все API после статьи habrahabr.ru/post/159217/

Agent_J 26 ноя 2012 в 19:10

Информацию о том какая это ошибка сообщает метод $user->getMessages(), а что с ней делать решать контроллеру.

nikita2206 27 ноя 2012 в 06:51

Модель вообще не должна даже сохранять **сама себя**. Это противоречит простой логике. (не говорите мне что такое ar, я знаю это)

witdex 27 ноя 2012 в 09:42

Интересно, какой это логике противоречит? Классический вариант модели в MVC, это когда модель должна(!) заниматься логикой. Называется «Активная модель». Почитайте: Wikipedia => Model-View-Controller => Наиболее частые ошибки
… и AR тут не причем

nikita2206 27 ноя 2012 в 11:11

По логике АР, ваша модель сама делает запрос к базе чтобы себя сохранить. MVC тут не при чем, это вообще другая песня.
Модель — это агностичная сущность, она не должна знать о том, что с ней вообще делают.
Главная проблема АР в том, что модели завязаны на инструмент. Это неправильно.
Ты не сможешь изменить инструмент когда тебе это понадобится.

И помимо этого, это просто не логично — сохраняет данные то, что сохраняет данные. Данные же сами себя не должны сохранять. (подразумевая что модель — это данные)

witdex 27 ноя 2012 в 12:27

О чем мы вообще говорим, об MVC, AR или о том как вы представляете модель?
Я говорю об MVC и конкретно об активной модели из этой концепции, где модель — «предоставляет знания: данные и методы работы с этими данными, реагирует на запросы, изменяя своё состояние».
А вы говорите насколько я понимаю о доменном объекте. Т.е. о пассивной модели которая по сути является структурой данных. Только я не пойму почему вы пытаетесь мне доказать что пассивная модель лучше или логичнее? Я ведь вам ответил на этот вопрос, во-первых активная модель это классический вариант концепции MVC, во-вторых я считаю как и в принципе почти все php популярные фреймворки (за исключением Doctrine 2) активную модель удобнее. Поэтому если мне нужны какие то сущности, не факт что это сущность мне нужна именно как php класс, может я захочу например xml использовать.
Так что тут дело вкуса и все.

nikita2206 30 ноя 2012 в 19:50

Прочитал комент и забыл… Да, я говорю о пассивной модели, и о принципе единой ответственности. По логике, я имею в виду по обычной человеческой логике, модели не ответственны за персистентность данных.

aavolkoff 27 ноя 2012 в 18:43

Вы, скорее всего, говорите о разделении логики программы и хранении/получении данных. Эта концепция хороша (снижение зависимостей), но она, как бы, зашита в «M» такой модели, как MVC. Её еще можно расширить, т.н. интерфейсами (классами-фасадами), которые еще больше снизят зависимость, но в MVC — это опять же всё в «M». То, как в примере реализована эта самая «M», конечно не кошерно, но это сделано, скорее всего, для упрощения туториала.

Agent_J 26 ноя 2012 в 18:39

Конечно не кошерно, только это контроллер, а не модель. Кстати, в тексте упоминается

Отправка вывода на экран напрямую из контроллера бывает оправданным, но так делать не стоит.

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

Я не буду говорить, что этот фреймворк лучше или хуже других, он принципиально другой. Рекомендую ознакомиться с этой статьёй habrahabr.ru/post/159217/

Xergin 26 ноя 2012 в 18:22

Предлагаю вот это безобразие:

if ($user->save() == true)

Заменить на:

if ($user->save())

В противном случае рекомендую использовать строгое сравнение

Agent_J 26 ноя 2012 в 19:09

Не то чтобы в данном случае это было ошибкой, но в целом вы правы. Исправил

KeepYourMind 26 ноя 2012 в 22:12

<?php

print_r(get_loaded_extensions());

можно заменить одной коммандой: php -m | grep phalcon

AotD 27 ноя 2012 в 08:26

… если у вас linux =)

KeepYourMind 27 ноя 2012 в 08:27

ок, просто php -m :)

Insa88 27 ноя 2012 в 10:13

вы так долго будете ставить и проверять))) этот вывод покажет только модули PHP и Zend.

Agent_J 27 ноя 2012 в 10:42

Пост не читай, сразу отвечай. Phalcon и есть модуль PHP.

Insa88 27 ноя 2012 в 10:56

Представьте я знаю, но эта команда его не выведет. В смысл не вникай, сразу осуждай?

Agent_J 27 ноя 2012 в 11:04

Insa88 27 ноя 2012 в 15:33

У вас есть ключик -с, теперь попробуйте без него.

Agent_J 27 ноя 2012 в 15:43

Что вы за бред несёте? Ключик -с говорит в каком месте php.ini искать

Insa88 27 ноя 2012 в 19:46

Бред заключается в том, что веб-сервер, cgi или cli могут иметь каждый свой php.ini, поэтому использовать php -m без ключа -c может ввести в заблуждение, особенно под linux'om (где зачастую php.ini разнесены). И если вы собираетесь использовать этот framework, то разумнее делать проверку как в уроке. Наверно я вас ввел в заблуждение про модули php и zend, имея ввиду лишь стандартные расширения php, которые сейчас уходят в PECL.

Agent_J 27 ноя 2012 в 20:06

Разумнее учить матчасть и не троллить на форумах и в блогах.

Используя любой инструмент вы должны понимать что он делает и как работает. Вы бы ещё предложили ключ -m не использовать

Insa88 27 ноя 2012 в 20:17

Судя по манере общения, вы тролль еще тот. А данная ветка как раз наглядно обращает внимание на мелочи в матчасте, и я считаю это уместно в статье-уроке, который ориентирован именно на новичков, потому как и без перевода в оригинале все ясно как 2x2. Мне вот не ясно за что вы на меня так огрызаетесь, я наоборот защищал ваш пример?

LavrenovNN 27 ноя 2012 в 02:15

Немного не в контексте данной статьи, но сообщество только формируется… и спросить негде.
Подскажите пожалуйста… имеется сторонний класс (группа классов) (php-sdk-facebook), могу ли я напрямую прикрутить к проекту библиотеку?

nikita2206 27 ноя 2012 в 06:53

А почему нет? В чем проблема? По сути фалкон это набор пхп-классов реализованных на си

Agent_J 27 ноя 2012 в 08:00

Кладёте библиотеку в свой проект и используете её. Всё как обычно

nolka 27 ноя 2012 в 04:14

Тестов производительности не хватает для полноты картины. Хотя это дело и написано на С, все-равно, интересно взглянуть на цифры.

signalizator 27 ноя 2012 в 04:35

Есть некоторые тесты

aavolkoff 27 ноя 2012 в 18:54

Тут еще: habrahabr.ru/post/159217/

nikita2206 27 ноя 2012 в 06:47

Я знаю что автор в этом не виноват, так написано в доках фалкона. Просто чтобы вы были осведомлены — фалкон не реализует внедрение зависимостей нигде. То что у него есть — это сервис локатор. К сожалению сейчас очень многие фреймворки так «путают».

Agent_J 27 ноя 2012 в 09:29

Вы немного не правы. Описание в данной статье действительно больше похоже на сервис-локатор, но надо понимать, что это базовая статья, которая не может охватить все подробности.

Давайте разберёмся в чём разница между внедрением зависимости и сервис-локатором. Об этом доходчиво написано в википедии

Условно, если объекту нужно получить доступ к определенному сервису, объект берет на себя ответственность за доступ к этому сервису: он или получает прямую ссылку на местонахождение сервиса, или обращается к известному «сервис-локатору» и запрашивает ссылку на реализацию определенного типа сервиса. Используя же внедрение зависимости, объект просто предоставляет свойство, которое в состоянии хранить ссылку на нужный тип сервиса; и когда объект создается, ссылка на реализацию нужного типа сервиса автоматически вставляется в это свойство (поле), используя средства среды.

Phalcon в полной мере реализует внедрение зависимостей, здесь Phalcon\DI является сервис-локатором, который внедряется в ключевые компоненты фреймворка.

Например, если посмотреть свойства объекта $user из этого туториала, то среди прочих вы обнаружите protected свойство _dependencyInjector, которое является ссылкой на сформированный в бутстрапе Phalcon\DI\FactoryDefault

nikita2206 27 ноя 2012 в 11:29

Хм, вообще я читал сорсы фалкона и по ним было видно что это просто SL, но, все таки, может быть я чего-то недопонял.
То, о чем вы говорите — это внедрение контейнера, который содержит зависимости. То, чем является внедрение зависимостей выглядит совсем по-другому — зависимый сервис получает сразу свои зависимости, а не контейнер (либо в конструктор, либо в методы-сеттеры).

Да, почитал сейчас статью в википедии. Ну, раньше я откровенно не понимал людей, которые смеялись над теми, кто считают википедию хорошим сорсом. А вот что говорит Фаулер:

The basic idea of the Dependency Injection is to have a separate object, an assembler, that populates a field in the lister class with an appropriate implementation for the finder interface

(link).

Если вкратце — сервис локатор имеет два минуса перед чистой инъекцией:
1. High coupling — вы завязываете всех зависимых на интерфейс локатора. То есть вы не сможете прозрачно сменить локатор, если у сменяемого интерфейс отличается от сменяющего.
2. Testability — в юнит-тестах нужно создавать локатор и добавлять ему нужные вам моки, это просто больше работы чем прямое внедрение.

Agent_J 27 ноя 2012 в 11:55

Я вас понял, видимо, я привёл не совсем корректный пример.

Зависимый сервис помимо контейнера (сервис-локатора) сразу получает и необходимые для его работы зависимости.
Например, в контроллере вы можете обратиться к зависимости Phalcon\Http\Request обратившись к свойству request, т.е. $this->request

Подробнее об этом можно почитать в документации docs.phalconphp.com/en/0.7.0/reference/di.html

nikita2206 27 ноя 2012 в 12:16

Единственный способ, который я там вижу, может вы про это:

$di->set("dependency", function ()  { return new Dependency; });
$di->set("depende", function () use ($di) { return new Depende($di->get("dependency")); });

Но это не описано в доках.

Agent_J 27 ноя 2012 в 13:20

Я не совсем понимаю что и куда вы хотите внедрить. Вы хотите увидеть пример DI средствами фреймворка?
Ну ваш пример вполне рабочий. Можно ещё сделать таким образом:

class Depende extends \Phalcon\DI\Injectable
{
}

class Dependency
{
}

$di->set('depende', 'Depende');
$di->set('dependency', 'Dependency');
var_dump($di->get('depende')->dependency); // object(Dependency)

nolka 27 ноя 2012 в 06:57

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

ПХПшечка, если и создавался изначально для веб, он изначально должен был быть примерно таким, как Phalcon. Я имею ввиду, сам подход. А то получается, что пхпшечка для веба — это что Си для разработчиков гуевых приложений — Писать гуевые приложения можно, но сколько геморроя…