Архитектура приложения. Средние и крупные проекты
Архитектура приложения. Средние и крупные проекты
Доброго времени суток всем.
По большей части интересует не столько архитектура самого проекта, сколько организация моделей и каких-то вспомогательных классов в проекте. Начну издалека и приведу несколько фактов об организации кода в своих проектах. Хотелось бы узнать мнение общества по этому поводу
1. Крайне редко придерживаюсь модульной структуры т.к. чаще всего имею дело с "узкоспециализированными" проектами. Т.е. это не стандартные ИМ, не простые порталы и пр. Не вижу смысла разбивать такие сайты на модули, хотя в них часто проскакивают какие-то распространенные компоненты типа блогов, новостей и т.д.
2. Структура проекта у меня самая обычная. После генерации каркаса (yiic webapp) никаких изменений в него не вношу и активно пользуюсь Gii. (Наверное отсюда-то у меня и все проблемы)
3. Под админку создается один единственный модуль backend. В нем лежат папки - components, actions, controllers, views. Модели у меня общие для всего проекта и лежат они в /protected/models. (наверное из-за этого в этих моделях и получается "свалка методов")
В итоге при работе с такой вот структурой мои модели похожи на огромную свалку методов. Они могут содержать до тысячи строк кода и по пол сотни разнородных методов, которые имеют хоть какое-то отношение к этой модели. В основном это геттеры типа - getDisplayUserName(), getPayoffString(), calculatePayoffSumm(), getDistrictsListData() и тп. причем некоторые из этих методов только для админки... (и вообще я не брезгую геттерами. При малейшей необходимости конкатенации строк в представлении я завожу новый геттер в модели ) В этих же моделях содержатся и стандартные методы rules(), search(), behaviors(), scopes() и пр.
Предполагаю, что нужно создать какую-то базовую модель, в которой будут содержаться основные методы и создать ещё одну модель под геттеры. Так же наверное нужно бы создать третью модель для бэкенда... Получится что то типа:
/protected/models/base/BaseUser - основные, общие методы для фронтенда, бекенда и вообще для всего приложения
/protected/models/User - геттеры для фронтенда
/protected/modules/backend/models/BackendUser - геттеры для бэкенда
насколько это правильно?
Вопросы:
1. Можно узнать кто как решает эту проблему и кто каких правил придерживается при проектировании?
2. Явно у меня огромный пробел в знаниях связанных с проектированием. Было бы здорово что-то почитать по этому вопросу, у кого-то есть на примете подходящая литература?
3. Может кто знает какие-то серьезные проекты с открытым исходным кодом и нормальной структурой? В общем хотелось бы посмотреть как нормальные люди решают эти проблемы
Относительно недавно наткнулся вот на эту замечательную статью http://www.yiiframework.com/wiki/155/th ... ject-site/, но в ней собственно нет решения моей проблемы.
Спасибо за внимание
По большей части интересует не столько архитектура самого проекта, сколько организация моделей и каких-то вспомогательных классов в проекте. Начну издалека и приведу несколько фактов об организации кода в своих проектах. Хотелось бы узнать мнение общества по этому поводу
1. Крайне редко придерживаюсь модульной структуры т.к. чаще всего имею дело с "узкоспециализированными" проектами. Т.е. это не стандартные ИМ, не простые порталы и пр. Не вижу смысла разбивать такие сайты на модули, хотя в них часто проскакивают какие-то распространенные компоненты типа блогов, новостей и т.д.
2. Структура проекта у меня самая обычная. После генерации каркаса (yiic webapp) никаких изменений в него не вношу и активно пользуюсь Gii. (Наверное отсюда-то у меня и все проблемы)
3. Под админку создается один единственный модуль backend. В нем лежат папки - components, actions, controllers, views. Модели у меня общие для всего проекта и лежат они в /protected/models. (наверное из-за этого в этих моделях и получается "свалка методов")
В итоге при работе с такой вот структурой мои модели похожи на огромную свалку методов. Они могут содержать до тысячи строк кода и по пол сотни разнородных методов, которые имеют хоть какое-то отношение к этой модели. В основном это геттеры типа - getDisplayUserName(), getPayoffString(), calculatePayoffSumm(), getDistrictsListData() и тп. причем некоторые из этих методов только для админки... (и вообще я не брезгую геттерами. При малейшей необходимости конкатенации строк в представлении я завожу новый геттер в модели ) В этих же моделях содержатся и стандартные методы rules(), search(), behaviors(), scopes() и пр.
Предполагаю, что нужно создать какую-то базовую модель, в которой будут содержаться основные методы и создать ещё одну модель под геттеры. Так же наверное нужно бы создать третью модель для бэкенда... Получится что то типа:
/protected/models/base/BaseUser - основные, общие методы для фронтенда, бекенда и вообще для всего приложения
/protected/models/User - геттеры для фронтенда
/protected/modules/backend/models/BackendUser - геттеры для бэкенда
насколько это правильно?
Вопросы:
1. Можно узнать кто как решает эту проблему и кто каких правил придерживается при проектировании?
2. Явно у меня огромный пробел в знаниях связанных с проектированием. Было бы здорово что-то почитать по этому вопросу, у кого-то есть на примете подходящая литература?
3. Может кто знает какие-то серьезные проекты с открытым исходным кодом и нормальной структурой? В общем хотелось бы посмотреть как нормальные люди решают эти проблемы
Относительно недавно наткнулся вот на эту замечательную статью http://www.yiiframework.com/wiki/155/th ... ject-site/, но в ней собственно нет решения моей проблемы.
Спасибо за внимание
Привет.
Re: Архитектура приложения. Средние и крупные проекты
UP
Не верю в то, что здесь нет людей владеющих вопросом..
Наверное сильно много букв в теме...
Не верю в то, что здесь нет людей владеющих вопросом..
Наверное сильно много букв в теме...
Привет.
- lancecoder
- Сообщения: 2532
- Зарегистрирован: 2012.06.26, 17:16
Re: Архитектура приложения. Средние и крупные проекты
она столько раз поднималась на данном форуме
погуглите толстые модели тонкие|худые контроллеры или наоборот
погуглите толстые модели тонкие|худые контроллеры или наоборот
Re: Архитектура приложения. Средние и крупные проекты
почему вопрос крутится в основном вокруг геттеров, у вас данные не модифицируются что ли совсем?
задавался подобным вопросом о структуре, здесь может, что подчерпнете viewtopic.php?f=3&t=11760
задавался подобным вопросом о структуре, здесь может, что подчерпнете viewtopic.php?f=3&t=11760
Re: Архитектура приложения. Средние и крупные проекты
Спасибо, буду искать. Хотя перед публикаций темы делал поиск по форуму, но видимо плохоlancecoder писал(а):она столько раз поднималась на данном форуме
погуглите толстые модели тонкие|худые контроллеры или наоборот
С контроллерами проблем нет как и с отображениями. Они ну очень тонкие, абсолютно вся логика свалена в одну кучу - модели
Так получается, что сетеры в моделях практически не присутствуют, т.к. setAttribute(s) вполне себе справляется с этой задачей. А если и нужна какая-то логика, то я её выполняю в валидаторахyan писал(а):почему вопрос крутится в основном вокруг геттеров, у вас данные не модифицируются что ли совсем?
За ссылку благодарен у меня очень схожая проблема. Понравилась идея с сервисами, буду раскручивать этот вариантyan писал(а):задавался подобным вопросом о структуре, здесь может, что подчерпнете viewtopic.php?f=3&t=11760
Привет.
Re: Архитектура приложения. Средние и крупные проекты
ой. буквально вчера в таких исходниках ковырялся... ужаснулся. простейшие вещи (которые реализуются через gii + допилить чуток) - реализованы такими костылями ужасными. проект поддерживать крайне сложно.
посмотри архитектуру https://github.com/clevertech/YiiBoilerplate
насчет жирности - сам больше люблю использовать жирные модели и худые контроллеры (если в контроллерах просто набросаны вызовы красиво\правильно названных функций - все становится читабельным и легко поддержуемым)
посмотри архитектуру https://github.com/clevertech/YiiBoilerplate
насчет жирности - сам больше люблю использовать жирные модели и худые контроллеры (если в контроллерах просто набросаны вызовы красиво\правильно названных функций - все становится читабельным и легко поддержуемым)
Re: Архитектура приложения. Средние и крупные проекты
эх, кстати по поводу бойлерплейтов, есть же и покруче:
https://github.com/tonydspaniard/yiinitializr-basic
https://github.com/tonydspaniard/yiinit ... termediate
https://github.com/tonydspaniard/yiinitializr-advanced
https://github.com/tonydspaniard/yiinitializr-basic
https://github.com/tonydspaniard/yiinit ... termediate
https://github.com/tonydspaniard/yiinitializr-advanced
Re: Архитектура приложения. Средние и крупные проекты
а чем круче? я особой разницы не увидел
Re: Архитектура приложения. Средние и крупные проекты
я вообще в подобных структурах не вижу решения проблемы изложенной топикстартером, они предназначены для проектов которые можно поделить на модули
Re: Архитектура приложения. Средние и крупные проекты
ну вообще то круче чем бойлерплейт значит еще не вникли.
Re: Архитектура приложения. Средние и крупные проекты
Кому-то удалось подружить Yiinitializr и giix?
Модель я сгенерировал, а вот CRUD хоть и сгенерировал, а вот запустить не получилось.
Обе примочки по своему расширили стандартный CController.
Yiinitializr - EController
giix - GxController
Попробовал сделать наследование у GxController от EController и в итоге получил ошибку.
Declaration of GxController::loadModel() should be compatible with that of EController::loadModel()
Как-то странно, что разработчики Yiinitializr не позаботились о giix..
Модель я сгенерировал, а вот CRUD хоть и сгенерировал, а вот запустить не получилось.
Обе примочки по своему расширили стандартный CController.
Yiinitializr - EController
giix - GxController
Попробовал сделать наследование у GxController от EController и в итоге получил ошибку.
Declaration of GxController::loadModel() should be compatible with that of EController::loadModel()
Как-то странно, что разработчики Yiinitializr не позаботились о giix..
Re: Архитектура приложения. Средние и крупные проекты
Разработчик Yiinitializr'а пишет, что они не поддерживают генерацию CRUD через gii (только модели).goryny4 писал(а):CRUD хоть и сгенерировал, а вот запустить не получилось
- SpiritAbsolute
- Сообщения: 187
- Зарегистрирован: 2013.12.29, 18:20
- Откуда: Калининград
- Контактная информация:
Re: Архитектура приложения. Средние и крупные проекты
На хабре вот такой способ нашел, буду пробовать сегодня. http://habrahabr.ru/post/207454/#crud
Почему генератор кода Gii не создаёт CRUD?
Если вы решили использовать сторонние классы EActiveRecord и EController, то вас поджидает небольшое разочарование — вы не сможете воспользоваться генератором кода Gii для создания CRUD из-за различий в структуре классов.
Проблема решается просто — расширением Gii, с помощью подключения собственного шаблона кода. Я подготовил для вас рабочий вариант.
Распаковываем архив в директорию ./common и добавляем её в качестве пути поиска генераторов в конфигурацию ./common/config/env/dev.php:
Теперь, щёлкнув на поле Code Template на странице Crud Generator, должен появиться выпадающий список, содержащий наш набор шаблонов yiinitializr-simple.
[/i]
Вообще застрял после установки на настройке приложения. Кто нибудь может подсказать конфигурацию для index.php в папке www basic приложения. Никак не могу разобраться с путями к своим конфигам.
По умолчанию там две строчки https://github.com/tonydspaniard/yiinit ... /index.php что передается во втором параметре. 'main' и в массиве третьим параметром. При том что в папке app/config
лежат 4 файла https://github.com/tonydspaniard/yiinit ... app/config и файла local там вообще нет.
Почему генератор кода Gii не создаёт CRUD?
Если вы решили использовать сторонние классы EActiveRecord и EController, то вас поджидает небольшое разочарование — вы не сможете воспользоваться генератором кода Gii для создания CRUD из-за различий в структуре классов.
Проблема решается просто — расширением Gii, с помощью подключения собственного шаблона кода. Я подготовил для вас рабочий вариант.
Распаковываем архив в директорию ./common и добавляем её в качестве пути поиска генераторов в конфигурацию ./common/config/env/dev.php:
Код: Выделить всё
'gii' => array(
...
'generatorPaths' => array('common.gii'),
),
[/i]
Вообще застрял после установки на настройке приложения. Кто нибудь может подсказать конфигурацию для index.php в папке www basic приложения. Никак не могу разобраться с путями к своим конфигам.
По умолчанию там две строчки https://github.com/tonydspaniard/yiinit ... /index.php
Код: Выделить всё
Yiinitializr\Helpers\Initializer::create('./../app', 'main', array('common', 'env', 'local'))->run();
лежат 4 файла https://github.com/tonydspaniard/yiinit ... app/config и файла local там вообще нет.