платформа зенда по сравнению с Kohana по сравнению с [закрытым] Symfony

9
задан aleemb 24 January 2010 в 06:19
поделиться

5 ответов

В вашем случае я бы пошел (в этом Заказ):

  1. Кохана
  2. Zend Framework

Так как они легче забрать (специально для новичка), чем симфония.

0
ответ дан 4 December 2019 в 08:15
поделиться

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

15
ответ дан 4 December 2019 в 08:15
поделиться

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

, которые сказали, что кажется, что настоящие трещины используют Symfony . Это может стать или может быть уже лучшим, самым универсальным, самым мощным каркасом там. Но это определенно нужно много понимания принципов программирования, а также веб-технологии Techonology и Server в целом.

Также очень мощный и намного проще начать с Zend Framework . Это может определенно сделать гораздо больше для вас, чем Кохана.

Если вы хотите легкую структуру, Кохана тоже хороший выбор. Это прошло в последние месяцы, и я думаю, что это быстро устанавливает себя как новый легкий любимый.

Так что все вообще, три рамотка, которые вы упомянули, - это три главные рамки на рынке PHP Framework на данный момент, и вы не допустите ошибку с любым из них.

6
ответ дан 4 December 2019 в 08:15
поделиться

Стиль Haskell является функциональным, а не обязательным! Вместо того, чтобы «делать это тогда», подумайте об объединении функций и описании того, что ваша программа будет делать, а не как.

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

main = untilM (isCorrect 42) (read `liftM` getLine)

Используется комбинатор, который многократно выполняет действие ( getLine извлекает строку ввода и read преобразует эту строку в целое число в этом случае) и проверяет ее результат:

untilM :: Monad m => (a -> m Bool) -> m a -> m ()
untilM p a = do
  x <- a
  done <- p x
  if done
    then return ()
    else untilM p a

Предикат (частично примененный в main ) проверяет догадку относительно правильного значения и соответственно реагирует:

isCorrect :: Int -> Int -> IO Bool
isCorrect num guess =
  case compare num guess of
    EQ -> putStrLn "You Win!"  >> return True
    LT -> putStrLn "Too high!" >> return False
    GT -> putStrLn "Too low!"  >> return False

Действие, которое должно выполняться до тех пор, пока игрок не угадает правильно,

read `liftM` getLine

Почему бы не сохранить его простым и просто не составить две функции?

*Main> :type read . getLine

<interactive>:1:7:
    Couldn't match expected type `a -> String'
           against inferred type `IO String'
    In the second argument of `(.)', namely `getLine'
    In the expression: read . getLine

Тип getLine - IO Последовательности , но read хочет получить чистую Последовательности .

Функция liftM из Control. Monad принимает чистую функцию и «поднимает» её в монаду. Тип выражения многое говорит о том, что оно делает:

*Main> :type read `liftM` getLine
read `liftM` getLine :: (Read a) => IO a

Это действие ввода-вывода, которое при выполнении возвращает значение, преобразованное с помощью read , Int в нашем случае. Напомним, что readLine - это действие ввода-вывода, которое дает значения Последовательностей , поэтому можно считать, что liftM позволяет применить чтение «внутри» монады ввода-вывода .

Пример игры:

1
Too low!
100
Too high!
42
You Win!
-121--1333337-

звучит так, будто на целевой машине не установлена среда выполнения visual c++. Вы можете установить его из здесь Поскольку, кажется, вы используете отладочные версии этих DLL, возможно, вам также нужно сначала построить свое приложение в режиме выпуска? Этот пост и этот имеют некоторые другие предложения, которые могут помочь...

-121--3246091-

ОБНОВЛЕНИЕ: Сейчас это 8 лет спустя, и Кохана больше не поддерживается. Ларавель будет моей текущей рекомендацией относительно простой, но очень мощной структуры PHP.


Несмотря на то, что ZF хорошо зарекомендовал себя и хорошо задокументирован, я бы предложил Кохану, поскольку она немного менее сложна. Очень легко начать работать с ним, просто загрузив или клонируя образец приложения из github .

Симфония не для начинающих. Я не согласен с тем, что рамки вообще не для новичков. Начиная с пустого файла и ни одна рамка не оставляет весь архитектурный дизайн кому-то, кто понятия не имеет, что они делают, начиная с облегченного рамки, такого как Кохана, дает вам хорошо организованную платформу и документацию, чтобы ударить по земле. Обучение OO без каких-либо примеров для руководства вам очень сложно, так как вы еще не знаете, как выглядит хороший проектировать.

После загрузки/клонирования приложения-образца Kohana, нажмите документы и вы будете писать хорошо -разработан код OO в кратчайшие сроки.

4
ответ дан 4 December 2019 в 08:15
поделиться

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

  1. Это легкий фреймворк, который является хорошей отправной точкой для полноценной разработки PHP, потому что он служит в качестве руководства по организации проекта на языке, который не имеет много структуры на своем собственном
  2. Вводит базовые концепции MVC.
  3. Имеет базовые возможности, которые будут полезны в любом PHP-проекте, например. кэширование, фильтрация данных и т.д.

Я бы перешел на Zend Framework, если бы вы по этим причинам планировали или стремились работать над большими проектами:

  1. Документация Коханы очень ограничена (она управляема для новичка, потому что в конечном итоге вы проглядываете вокруг и видите, что делает фреймворк "галочкой", чтобы они не увидели этот зловещий святой код, который является плюсом; но в крупном проекте со сроками исполнения это раздражает)
  2. Кохана применяет некоторые соглашения, что часто неудобно в крупных проектах
  3. Недостаток зрелых возможностей, которые полезны в "корпоративной" разработке и т.д. g. Приличная система юнит-тестирования (в Кохане есть простейшие phpunit-модули, и вы, конечно, можете использовать базовый PHPUnit, но, напротив, Zend Framework расширил функционал PHPUnit до лучшего набора его фреймворка)
  4. Лучшая поддержка. За Zend фреймворком стоит компания Zend, а также огромное сообщество. Это огромная победа для них, потому что она пронизывает все, что связано с фреймворком, например, конфигурация продумана намного лучше в Zend framework, более надежные функции безопасности, правильная автозагрузка классов, основанная на PEAR-интерфейсе, а также множество компонентов, внесенных в него. Некоторые из этих преимуществ можно пожимать плечами при старте, но они становятся неоценимыми при работе над большими проектами.

Я не использовал symfony, но из того, что я могу сказать, у него также есть некоторые полезные возможности, как только вы лучше освоите PHP (лучший ORM, лучшие строительные леса и т.д.). Справка: Кохана - хорошее начало, но я бы не советовал там заниматься роутингом, если вы планируете попасть на PHP за пределы маленьких сайтов.

1
ответ дан 4 December 2019 в 08:15
поделиться
Другие вопросы по тегам:

Похожие вопросы: