Комментарии 25
1) habrahabr.ru/add/translation/
2) habrahabr.ru/sandbox/add/
3) Оформление ужасное. Переносы строк где попало, код не читаем.
2) habrahabr.ru/sandbox/add/
3) Оформление ужасное. Переносы строк где попало, код не читаем.
Прошу меня понять. Первый раз добавляю пост. Пол часа пыхтел.
про 1) — не заметил. про 2) — не открывается ссылка.
как код сделать читаемым?
про 1) — не заметил. про 2) — не открывается ссылка.
как код сделать читаемым?
2) Киньте другу (не зарегистрированному), у него откроется.
3) А вы сами не можете посмотреть, что нет?
3) А вы сами не можете посмотреть, что нет?
По поводу кода — сделайте отступы и подсветите синтаксис(я обычно использую этот сервис).
А за статью спасибо. Пусть и перевод, но видно, что сил в него вложено больше, чем многие вкладывают в свои статьи. Плюсики и лучики добра Вам. Пишите ещё.
А за статью спасибо. Пусть и перевод, но видно, что сил в него вложено больше, чем многие вкладывают в свои статьи. Плюсики и лучики добра Вам. Пишите ещё.
Извините, что не по теме. Хотел бы изучить Zend Framework ;)
Есть ли какая-нибудь литература? Если есть — порекомендуйте что.
Есть ли какая-нибудь литература? Если есть — порекомендуйте что.
Чем Zend Framework лучше других фреймворков?
Об этом уже не раз писали на Хабре, используйте поиск.
В этом вопросе новичок, поэтому если некорректно что-либо, поправьте без плюсов/минусов, ответьте, пожалуйста.
На это вам, наверное, никто однозначно не ответит.
Это как если бы вы выбирали автомобиль, то руководствовались какими-то нужными вам параметрами — скорость, универсальность, проходимость, комфорт, цена и т.д.
Так что ответа на ваш вопрос сильно зависит от ваших потребностей. Если таковых по сути нет, то посмотреть его стоит в любом случае. Там есть грамотные реализации паттернов и приёмов программирования, хороший код, подробный, но, порой, непростой мануал, да и Zend известная компания.
По поводу вашего вопроса вспомнил анекдот.
— Армяне лучше чем грузины.
— Чем?
— Чем армяне.
Это как если бы вы выбирали автомобиль, то руководствовались какими-то нужными вам параметрами — скорость, универсальность, проходимость, комфорт, цена и т.д.
Так что ответа на ваш вопрос сильно зависит от ваших потребностей. Если таковых по сути нет, то посмотреть его стоит в любом случае. Там есть грамотные реализации паттернов и приёмов программирования, хороший код, подробный, но, порой, непростой мануал, да и Zend известная компания.
По поводу вашего вопроса вспомнил анекдот.
— Армяне лучше чем грузины.
— Чем?
— Чем армяне.
Как по мне, использование бизнес-логики в моделях также не очень верно, как и в контроллерах. Ведь модель по сути это операции по работе с данными, их получение, сохранение, обновление и т.д. Если меняется бизнес-логика приложения это может и не затронуть ни модель, ни контроллер, ни представление.
Хотя я видел бизнес-логику и в контроллерах и в моделях, а в самых запущенных случаях, и в представлениях, сам я, зачастую, инкапсулирую логику в отдельные классы, к которым обращаюсь в контроллере, а уже эти классы в свою очередь оперируют с моделью.
Поделитесь, как делаете вы?
Хотя я видел бизнес-логику и в контроллерах и в моделях, а в самых запущенных случаях, и в представлениях, сам я, зачастую, инкапсулирую логику в отдельные классы, к которым обращаюсь в контроллере, а уже эти классы в свою очередь оперируют с моделью.
Поделитесь, как делаете вы?
Скорее всего автор имел в виду, чтоыб держать всю бизнес-логику в одном месте.
Я думаю, что бизнес-логика по сути ближе к контроллерам.
Из теории MVC — аналог данных, представления и логики (эт когда мы простейшие три слоя используем).
Так что я бы в контроллере это всё держал — extends же ещё не отменили?
Я думаю, что бизнес-логика по сути ближе к контроллерам.
Из теории MVC — аналог данных, представления и логики (эт когда мы простейшие три слоя используем).
Так что я бы в контроллере это всё держал — extends же ещё не отменили?
Есть мнение, что контроллеры должны быть «тонкими» — weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model.
Как мне кажется, тут нет единственно правильного ответа.
Как мне кажется, тут нет единственно правильного ответа.
Дык Вы посмотрите — там автор всю логику в контроллер и запихивает!
А то, что к данным — то в модель.
Напр., пусть у нас есть уже в модели:
человек.имя и человек.имя.
Тогда логично будет в модели же и сделать что-то автовычисляемое, типа человек.ФИО. И не в контроллере. Там примерно такой пример и даётся.
А вот когда у нас где-то нужно принимать решения, когда if на сцену выходит — то это явный кандидат на логику в контроллере.
А то, что к данным — то в модель.
Напр., пусть у нас есть уже в модели:
человек.имя и человек.имя.
Тогда логично будет в модели же и сделать что-то автовычисляемое, типа человек.ФИО. И не в контроллере. Там примерно такой пример и даётся.
А вот когда у нас где-то нужно принимать решения, когда if на сцену выходит — то это явный кандидат на логику в контроллере.
Спасибо за статью, её я читал в начале работы с ZF. Не увидел больших разногласий с тем, что я написал выше. Модель так или иначе отвечать за данные, это могут быть данные из БД, данные от веб-сервиса, данные о пользователе и т.д. Именно такие модели я и использую в своих приложениях.
В статье предлагается создавать «толстые» модели, мне же кажется, что для логики можно создавать отдельный слой.
Вопрос был о бизнес-логики, которая может одновременно оперировать с несколькими моделями, и, по-моему, пихать такую логику в одну модель не совсем верно.
Возможно, это дело вкуса, но мне так удобнее.
В статье предлагается создавать «толстые» модели, мне же кажется, что для логики можно создавать отдельный слой.
Вопрос был о бизнес-логики, которая может одновременно оперировать с несколькими моделями, и, по-моему, пихать такую логику в одну модель не совсем верно.
Возможно, это дело вкуса, но мне так удобнее.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Zend Framework советы и трюки