Кто нибудь реализовывал такое приложение, как ТС из этого топика http://www.yiiframework.ru/forum/viewtopic.php?f=19&t=22322 ?

сейчас нужно так же сделать, пока не понимаю с какой стороны подойти

я точно не скажу, но мне кажется, что так сейчас работают все популярные js framework'и

берут json данные с сервера, и на клиенте строят виды

делаешь апи, делаешь js-клиент. подойди с любой стороны)

можешь взять готовенький rest от yii, там уже 90% backend'а сделано за тебя

Проблема не в том чтобы на сервере отдавать. Проблема сделать front на современном js-фреймворке ) Технологий много. А на сервере, хоть json, хоть полноценный REST, хоть graphql

но судя по вопросу, с js-фреймворками ты совершенно не знаком. Удачного секса )

но судя по вопросу, с js-фреймворками ты совершенно не знаком. Удачного секса )

:D

Artur, бери Angular2, по нему много в интернете гайдов и доков. Если руки прямые, то никаких проблем с освоением не должно быть

заодно ts подучишь)

это понял, хочу сделать максимально расширяемый продукт. сейчас проект работает на yii2 basic. Проект, 1ый год, переходил из рук в руки. Вся логика в моделях, что не хорошо. и сейчас с этим много проблем. как и куда можно вынести логику именно в backend приложении? Те же связи, транзакции?

я ебусь только с бэкендом )

с js ебется другой )

так что тогда из той темы заинтересовало?

На клиенте все как было так и будет. Только данные отдаются не в готовом html, а в виде json данных. А на клиенте по этим данным рисуется весь html

так что тогда из той темы заинтересовало?

описание )

не, давай конкретнее

что хочешь?

с клиентом понятно. тут вопрос архитектуры бекенда

На клиенте все как было так и будет. Только данные отдаются не в готовом html, а в виде json данных. А на клиенте по этим данным рисуется весь html

* блин на сервере как было...

как было мне не надо ) слишком толстые модели

почитай про graphql

да не надо ему вообще это.

а что надо не понятно

(

На клиенте все как было так и будет. Только данные отдаются не в готовом html, а в виде json данных. А на клиенте по этим данным рисуется весь html

Это зовётся SPA. Мы в компании перешли на этот подход. Очень удобно делить деятельность frontend и backend разработчиков. Yii рендеринг используем только в админке, а директорию frontend в advanced template переименовали в rest, там чисто REST интерфейсы

короче, надо сделать сервак чисто для АПИ. будут модели для таблиц из базы, будут active контроллеры (рест апи). куда и как можно вынести бизнес логику приложения?

короче, надо сделать сервак чисто для АПИ. будут модели для таблиц из базы, будут active контроллеры (рест апи). куда и как можно вынести бизнес логику приложения?

для апи или не апи - разницы нет. только вьюшки исчезают.

где хранить бизнес логику? в сервисах

что в обычном приложении, что в рест

Как организовать эти сервисы? просто класс, в которых находится вся логика? или что? может есть примеры реализаций сервисов?

условно говоря да. бизнес логику, которая завязана на состоянии одной модели, оставляем в модели (типа changeStatus, addOrderItem). Бизнес-логику касающуюся нескольких моделей и инфраструктурных вещей (типа отправить письма, уведомления, итд) - в сервисы

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

одна модель отвечает за работу с БД, другая за изменения аватара, принимает на вход модель для работы с бд и объект для работы с хранилищем

модель должна хранить свое состояние и иметь возможность изменять себя. вся остальная бизнес-логика - в сервисы

Это из симфони пришло) Ну тут игра терминами идет

Я наверно то же самое имею ввиду

в симфони тоже такого нет. есть модели, есть сервисы

хм, могу ошибаться, но похожие слова я слышал от гуру(вроде как) в симфони)

похожие - какие?

в симфони вообще модели нет

модель должна хранить свое состояние и иметь возможность изменять себя. вся остальная бизнес-логика - в сервисы

модель должна хранить свое состояние и иметь возможность изменять себя. вся остальная бизнес-логика - в сервисы

а, ну это стандартная практика программирования

в книжках пишут

Просто в классы запихать тоже не айс получается. Нужны еще как минимум command bus и еще какое-нибудь подобие service layer из слоистой архитектуры.

Просто в классы запихать тоже не айс получается. Нужны еще как минимум command bus и еще какое-нибудь подобие service layer из слоистой архитектуры.

просто классы и будут service layer

service layer - это не слоистая архитектура. просто слой любой хорошей архитектуры

слоистая - это более широкая парадигма

но в целом да, типа того

service layer - это не слоистая архитектура. просто слой любой хорошей архитектуры

Ну так слой же.))

ну так даже в обычной yii-лапше есть слои - контроллер, вьюшки, моделе-сервисо-хелперы, они же бд-адаптеры

ну так даже в обычной yii-лапше есть слои - контроллер, вьюшки, моделе-сервисо-хелперы, они же бд-адаптеры

Ну да. вообще-то. Я имел ввиду, что все-таки Service layer по хорошему нужно строить. Это ведь не просто будет набор классов, у них должен быть интерфейс определящий взаимодействие. А это уже нужно думать.

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

здраствуйте

Ну да. вообще-то. Я имел ввиду, что все-таки Service layer по хорошему нужно строить. Это ведь не просто будет набор классов, у них должен быть интерфейс определящий взаимодействие. А это уже нужно думать.

Заранее все не предугадаешь, я начинаю с малого, создаю объект, который делает что то одно, в конструкторе описываю зависимости(то что данный объект делать не "хочет"), создаю интерфейсы для зависимостей, которым должны соответствовать инкапсулируемые объекты. и вот так от малого к большему шагаю.

а есть у когото опыт разработки личного кабинета ?

а есть у когото опыт разработки личного кабинета ?

вряд ли. слишком редкая задача

http://web.archive.org/web/20081007231834/http://www.yiiframework.com/

Ого

Скоро 10 лет будет

ага

но есть и древнее

cakephp

Так это же другой фреймворк)

да другой

а есть у когото опыт разработки личного кабинета ?

Как обычно вопросы будут в личке ? Или какой вопрос то

ERROR: S client not available

backend/frontend/common и есть модуль. backend не знает о frontend, а frontend о backend. А common о frontend и backend. Все хорошо разделено. Не нужно создавать кучу модулей по ответственности, когда это не нужно.

Мне модули backend/frontend/common напоминают бандлы вы симфони. Когда модуль api, front еще 100500 бандлов зависят от CoreBandle. Вроде они пытаются разделить приложение, а получается не очень, все равно зависимость есть от CoreBandle. Получается common как "модуль" не самодостаточен. И адвантед шаблон это попытка уйти от проблем "не возможности положить контроллер в субдерикторию" без костылей. Что думаешь @zelenin

Как обычно вопросы будут в личке ? Или какой вопрос то

Вобще хотелось посмотреть на реализацию как он организован внутри ... может остались демки с проэкта, поклацать -)

@ExileeD сразу оговорюсь по терминологии - под модулем я имею в виду термин, используемый в книгах по программированию в общем - логически выделяемый пакет схожего функционала. бандлы в симфони - это обычно реализация модуля в контексте симфони, как модуль yii - реализация модуля в контексте yii. Как должно быть - должен быть независимый модуль + бридж в любом виде к конкретному фреймворку - фреймворкозависимые адаптеры, экшны и прочая шелуха (не бизнес-логика). Такие реализации есть например в виде какой-либо независимой либы (Doctrine) плюс например бандла для симфони (DoctrineBundle). Что в контексте выше сказанного такое common, frontend, backend? ничего. Зависимость от CoreBundle? зависеть должны адаптеры модуля к фреймворку - это нормально.

@ExileeD сразу оговорюсь по терминологии - под модулем я имею в виду термин, используемый в книгах по программированию в общем - логически выделяемый пакет схожего функционала. бандлы в симфони - это обычно реализация модуля в контексте симфони, как модуль yii - реализация модуля в контексте yii. Как должно быть - должен быть независимый модуль + бридж в любом виде к конкретному фреймворку - фреймворкозависимые адаптеры, экшны и прочая шелуха (не бизнес-логика). Такие реализации есть например в виде какой-либо независимой либы (Doctrine) плюс например бандла для симфони (DoctrineBundle). Что в контексте выше сказанного такое common, frontend, backend? ничего. Зависимость от CoreBundle? зависеть должны адаптеры модуля к фреймворку - это нормально.

У тебя общение между модулями проходит через события ? Или как ты строишь архитектуру на yii2. Как по мне core, common в модулях, бандлах это не очень хорошо

У тебя общение между модулями проходит через события ? Или как ты строишь архитектуру на yii2. Как по мне core, common в модулях, бандлах это не очень хорошо

подходы разные. я не говорил про core, common в модулях.

подходы разные. я не говорил про core, common в модулях.

Интересно услышать про твой подход, если конечно у тебя есть желание и время. А то проблема в yii2 сообществе, нету толковых проектов в ОS.

ddd, es, cqrs - вот такое люблю. можно книжки почитать. на yii2 не пишу, но реализация архитектуры от фреймворков не зависит. если есть более конкретные вопросы, я за.

ddd, es, cqrs - вот такое люблю. можно книжки почитать. на yii2 не пишу, но реализация архитектуры от фреймворков не зависит. если есть более конкретные вопросы, я за.

(d)dd - data или domain ?

domain

расшифруйте аббревиатуры, пожалуйста для совсем нуба, не знающего теорию :)

domain driven design, event sourcing, command query responsibility segregation

если не путаю. гуглятся на раз-два

спасибо, обязательно погуглю и почитаю

начинать изучение с первого - волосы сразу станут шелковистыми

ибо знания архитектуры ограничиваются практическими навыками

ddd, es, cqrs - вот такое люблю. можно книжки почитать. на yii2 не пишу, но реализация архитектуры от фреймворков не зависит. если есть более конкретные вопросы, я за.

Тут скорее вопрос как люди разделяют api, front и т.д В других фреймах я разделяю неймспейсами. А тут контроллеры не положишь в отдельный неймспейс. даже в субдиректорию нельзя. Не знаю понятно ли я обьясняю.

где тут? в yii2? в реализации модуля?

Просто в yii2.

Тут скорее вопрос как люди разделяют api, front и т.д В других фреймах я разделяю неймспейсами. А тут контроллеры не положишь в отдельный неймспейс. даже в субдиректорию нельзя. Не знаю понятно ли я обьясняю.

у тебя есть домен (вся твоя бизнес область) и отдельно где угодно контроллеры, которые выводят данные

в yii2 можно контроллеры куда угодно класть. есть же controllerNamespace или что-то такое

Там нельзя так Admin/DashboardController, Api/UserController Вложености нету.

да как нельзя, если можно?

ну кароч исхитриться можно если даже нельзя (в Module::init() переопределять например - не суть)

https://github.com/yiisoft/yii2/issues/1520 без костылей этого не добиться

ну и не надо. размещай плоско.

Немного не понял

https://github.com/yiisoft/yii2/pull/13517#issuecomment-279949801

Это он предложил или так уже можно сейчас делать?

Нарооод

Так сейчас этого нет в реализации?

narod.ru

Я просто не могу найти, но может кто знает