Comments 29
хабракат? :)
хабракат забыли :)
Прошу прощения за забытый хабракат — это было не умышленно.
На DevZone лежит аналогичная статья уже давно. В обеих статьях отсутствует информация, как научить Doctrine понимать при генерации модели рекомендуемую модульную структуру ZF. Например, сейчас все модели сваливаются в одну папку — MODELS_PATH, а хотелось бы, чтобы модель появлялась в папке соответствующего модуля. Кто-то такое реализовывал?
А зачем жестко связывать модули с моделями? Модели могут использоваться в любом модуле проекта.
Я понял о чем вы говорите. Если для вас так важна модульная структура, в которой модели между модулями не пересекаются — попробуйте поменять SandboxCli таким образом, чтобы консольная команда принимала в аргументах схему модкли модуля и имя модуля. На основании этих данных разбрасывайте вашу модель по местам назначения. Думаю это реализовать достаточно просто. Возможно чуть позже выложу вариант с этой реализацией.
Присоединяюсь к вопросу о том, как сделать так, чтобы все модели не сваливались в одну папку, а располагались также как и файлы в ./schema.
Кстати, ИМХО самое место для моделей в ./application/models.
Кстати, ИМХО самое место для моделей в ./application/models.
Вообще написано хорошо, старательно. НО! Model помещать в library нельзя — это грубое нарушение. Автору стоит почитать, зачем нужен каталог library в ZF. Да, самое место им действительно в /application/models, или где-то в другом месте, но в пределах каталога /application
Позволю себе с вами поспорить. ИМХО, то о чем вы говорите — не грубое нарушене, а предпочтения разработчика все-таки. Моя позиция основывается вот на чем. Я несколько абстрагировался от концепции исключительно веб-приложения. По сути вы говорите о концепции MVC. Я же думаю о M-VC. Т.е. модель как бы в стороне от вью-контроллер. Веб-приложение — это лишь частный случай реализации интерфейсов и взаимодействия с пользователем программного комплекса. Но ведь никто не заставляет нас ограничиваться лишь вебом. В сложном проекте у вас могут быть различные VC, построенные на одной модели: веб-фронтенд, консольный клиент, сервис-приложения, GTK в конце-концов.
Вот пусть они лежат в папке application/. Т.е. там у нас вью-контроллеры. И папка модель там будет выглядеть несколько нелепо.
А значит, что с этой точки зрения, модель есть не что иное, как БИБЛИОТЕКА общих функций бизнес-логики для бесконечного набора вью-контроллеров. Поэтому я и предложил вынести ее в library/. И это всего лишь мое предпочтение, как разработчика, основанное на внутренней философии. Вы же в силах поменять структуру так как считаете нужным. А с формулировкой «грубое нарушение», простите, я не согласен.
Вот пусть они лежат в папке application/. Т.е. там у нас вью-контроллеры. И папка модель там будет выглядеть несколько нелепо.
А значит, что с этой точки зрения, модель есть не что иное, как БИБЛИОТЕКА общих функций бизнес-логики для бесконечного набора вью-контроллеров. Поэтому я и предложил вынести ее в library/. И это всего лишь мое предпочтение, как разработчика, основанное на внутренней философии. Вы же в силах поменять структуру так как считаете нужным. А с формулировкой «грубое нарушение», простите, я не согласен.
Каталог application включает в себя все то, что касается данного сайта — приложения.
Каталог library включает в себя фреймворки (Zend, ваш собственный, другие фреймворки и библиотеки), которые используются в самых разных приложениях. Если у вас есть несколько различных систем, работающих с одной подсистемой, то логично вынести эту подсистему в library (в качестве примера — собственная реализация captcha).
В вакууме (в идеале) в репозитории кода каждый подкаталог library должен представлять собой связь с другим репозиторием, в котором ведется разработка данного фреймворка/библиотеки.
При создании сайта (не хомпэйдж, не блог, не визитка, а что-то по-сложнее и уникальнее) наверное 70—80% кода годятся только для данного сайта, значит это application, а не library.
Что касается `веб-фронтенд, консольный клиент, сервис-приложения, GTK в конце-концов`, так это не разные контроллеры, это разные View. И тут вы как раз опять грубо нарушаете идеологию MVC.
Впрочем, ваша философия тоже имеет право на жизнь. И я не переубеждаю вас (наверное это бесполезно, так же как переубеждать меня), но сам с ней не согласен. Подозреваю, что на практике ваш подход иногда будет оптимален, но это будет лишь исключение из правил. Для основной массы сайтов ваши аргументы можно рассматривать только как философию, не имеющую практических предпосылок.
Каталог library включает в себя фреймворки (Zend, ваш собственный, другие фреймворки и библиотеки), которые используются в самых разных приложениях. Если у вас есть несколько различных систем, работающих с одной подсистемой, то логично вынести эту подсистему в library (в качестве примера — собственная реализация captcha).
В вакууме (в идеале) в репозитории кода каждый подкаталог library должен представлять собой связь с другим репозиторием, в котором ведется разработка данного фреймворка/библиотеки.
При создании сайта (не хомпэйдж, не блог, не визитка, а что-то по-сложнее и уникальнее) наверное 70—80% кода годятся только для данного сайта, значит это application, а не library.
Что касается `веб-фронтенд, консольный клиент, сервис-приложения, GTK в конце-концов`, так это не разные контроллеры, это разные View. И тут вы как раз опять грубо нарушаете идеологию MVC.
Впрочем, ваша философия тоже имеет право на жизнь. И я не переубеждаю вас (наверное это бесполезно, так же как переубеждать меня), но сам с ней не согласен. Подозреваю, что на практике ваш подход иногда будет оптимален, но это будет лишь исключение из правил. Для основной массы сайтов ваши аргументы можно рассматривать только как философию, не имеющую практических предпосылок.
> 'это не разные контроллеры, это разные View.'
На практике, то и другое, как правило, так как в зависимости типа приложения будет меняться его поведение. Банальный пример — фронтенд и бэкенд приложения, если рассматривать в рамках только веба.
> 'философию, не имеющую практических предпосылок'
Как раз наоборот. она вытекает из практики. Я очень хорошо понимаю вашу позицию, поверьте. А вы просто попробуйте выйти за ее рамки и, возможно, вы увидите смысл и в моей ;)
Пы.Сы. Далеко не все — сайты. В принципе я должен был, конечно же, указать о чем речь, дабы не порождать подобные споры. Исправлю в следующей статье, где намерен описать несколько типовых архитектур.
На практике, то и другое, как правило, так как в зависимости типа приложения будет меняться его поведение. Банальный пример — фронтенд и бэкенд приложения, если рассматривать в рамках только веба.
> 'философию, не имеющую практических предпосылок'
Как раз наоборот. она вытекает из практики. Я очень хорошо понимаю вашу позицию, поверьте. А вы просто попробуйте выйти за ее рамки и, возможно, вы увидите смысл и в моей ;)
Пы.Сы. Далеко не все — сайты. В принципе я должен был, конечно же, указать о чем речь, дабы не порождать подобные споры. Исправлю в следующей статье, где намерен описать несколько типовых архитектур.
> > 'это не разные контроллеры, это разные View.'
>
> На практике, то и другое, как правило, так как в зависимости типа приложения будет
> меняться его поведение. Банальный пример — фронтенд и бэкенд приложения, если
> рассматривать в рамках только веба.
А вот это уже зависит строго от того, как делать. Например, разделять фронтэнд и бэкэнд вовсе не обязательно. Правда я и сам так делаю, но только потому что так проще, но нельзя сказать, что так лучше. Но в любом случае, на практике легко можно сделать так, что контроллеры фронт- и бэкэнда будут одинаковыми. Опять таки, View разный, контроллеры одни и те же. (Но я не говорю, что они не могут быть разными, — могут).
Если делать все _правильно_, то проблемы «разные» контроллеры быть не должно. Если такая проблема возникает, наверное опять недопонимание чего-то…
>
> На практике, то и другое, как правило, так как в зависимости типа приложения будет
> меняться его поведение. Банальный пример — фронтенд и бэкенд приложения, если
> рассматривать в рамках только веба.
А вот это уже зависит строго от того, как делать. Например, разделять фронтэнд и бэкэнд вовсе не обязательно. Правда я и сам так делаю, но только потому что так проще, но нельзя сказать, что так лучше. Но в любом случае, на практике легко можно сделать так, что контроллеры фронт- и бэкэнда будут одинаковыми. Опять таки, View разный, контроллеры одни и те же. (Но я не говорю, что они не могут быть разными, — могут).
Если делать все _правильно_, то проблемы «разные» контроллеры быть не должно. Если такая проблема возникает, наверное опять недопонимание чего-то…
> А вот это уже зависит строго от того, как делать. Например, разделять фронтэнд и бэкэнд вовсе не обязательно.
Совершенно верно :) Это можно разделять политикой прав. Я лишь привел банальный пример, понятный каждому. И все таки разные типы приложения так или иначе будут порождать разные контроллеры, так как у них как правило РАЗНОЕ ПРЕДНАЗНАЧЕНИЕ. (Консолное и веб-приложение будут решать разные задачи). Такое случается часто.
Вы меня натолкнули на идею статьи по архитектурам, за что вам отдельное спасибо :). Откланиваюсь.
Совершенно верно :) Это можно разделять политикой прав. Я лишь привел банальный пример, понятный каждому. И все таки разные типы приложения так или иначе будут порождать разные контроллеры, так как у них как правило РАЗНОЕ ПРЕДНАЗНАЧЕНИЕ. (Консолное и веб-приложение будут решать разные задачи). Такое случается часто.
Вы меня натолкнули на идею статьи по архитектурам, за что вам отдельное спасибо :). Откланиваюсь.
Вот как и обещал, мои мысли — приглашаю обсудить и внести коррективы:
mikhailstadnik.com/mvc-structures
mikhailstadnik.com/mvc-structures
ИМХО, наблюдается некий hype вокруг Doctrine и у нас и у них (распробовали?)… вот тут уже и формы в ZF из Doctrine-моделей генерируют…
>А поскольку сами свойства скрыты в рамках одного свойства класса-родителя, то ни одна среда разработки никогда вам не подскажет их в автокомплите
э, ну, вообще-то, PDT уже позволяет, с помощью @property
э, ну, вообще-то, PDT уже позволяет, с помощью @property
В Zend Studio @property и @method не подхватываются :( У меня ZS 6.1 Build ID: 20080907
В данном случае можете переделать/добавить функционал в класс SandboxCli, для генерации @property блоков. Я же лично отдал предпочтение get и set методам — они дают больше возможностей. Но это — личные предпочтения.
отлично! спасибо!
Аналогичная статья уже была, и даже переведена на русский: ruben.savanne.be/articles/integrating-zend-framework-and-doctrine
Sign up to leave a comment.
Тюнинг Zend Framework + Doctrine