это шуточное спасибо, видишь смайлик в конце)))

Ото оно как)

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

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

Задать в базе тип аккаунта например булев и крутить с помощью его, все акки в одной табле, отличаются одним столбцом

Похоже, я тут стану скоро сильно более частым гостем. Таки забиваем мы на поддержку первой версии фреймворка. Настроились на апгрейд до второй и потом до третьей версии.

Там, конечно, вкусно получается в плане первого Yii. Но коробило всегда, что этим никто кроме нас пользоваться не будет. )

А почему не сразу на третью?

У нас уже вынесенный active-record в том виде, что подключается даже к Битрикс. Почти полный тайп-хинтинг и т.п.

Я лучше если премя попробую третий помочь ребятам попилить. Хотя временной вопрос - это всегда жесть. )

Тем более что мы двигались с ними параллельно и в одном направлении.

А почему не сразу на третью?

Ну там очень мало что есть от третьего пока.

Да и садить проекты федерального масштаба на dev-master ?

Я пользую его для одного "домашнего" проекта. Так что в курсе того что куда движется.

Так что, again, всем привет! )

Когда релиз 3 версии?)

Привет ✌️

Когда релиз 3 версии?)

Так все же знают: когда будет готов. ?

?

Опять все переписывают?)

Ну вот пока что yii2 проект работает на dev-master с минимальной доработкой. Пока-что всё идёт хорошо.

Баттл был нехилый кстати в плане того куда обновляться. Метались между Spring, Symfony, Yii, Laravel и некоторыми менее известными решениями.

laravel))

В финальной битве сошлись Yii и Spring. Symfony и Laravel спасовали достаточно быстро. Spring замочил Symfony, а Laravel - самоликвидировалась.

В итоге выбирали скорее концепцию разработки, а не собственно фреймворк.

Я был удивлён насколько резво Spring давил почти всё что есть в мире php. Нет смысла с ним тягаться. Yii оказался одним из немногих, кто именно что php-way.

Ну реально, зачем Symfony, если есть Spring? ?

Разве если кто из разрабов неспособен в Java, а реально нужно прямо энтерпрайз.

Кто-то неплохо поднимает? ?

Кто-то неплохо поднимает? ?

или хорошо наебывет %)

Что тут за такое принято? Просто удалить или веник с тазиком выдать?

Задать в базе тип аккаунта например булев и крутить с помощью его, все акки в одной табле, отличаются одним столбцом

Это, получается, им нужен будет разные компонет User? Как это разграничить? Модулями отдельными?

Опять все переписывают?)

В итоге без хорошего напильника не обойдётся. Если они решили ввести полный, насколько возможно, тайп хинтинг, то как минимум его расставить по проекту очень много где придётся.

laravel))

Напомните, почему такой скепсис про ларавель?

Вопрос серьезный, если что ) Я правда не знаю.

Нет скепсиса. Он классный. Удобный. Но по своей природе он нечто среднее между Symfony и Yii. Прибавить сюда кадровый вопрос и цену, которую платит CPU за его удобства, то получается что он не так уж и интересен бизнесу.

Ну и поддержать отечественного производителя. Это же приятно.

Мне почему-то Laravel очень Rails всегда напоминал. Не фукнционалом, так подходом к экосистеме разработки.

В общем, Лару всегда любил, но профессионально с ней практически не пересекался. Её ниша и моя они, так вышло, давно не пересекаются.

И нужно учесть, что тут всё ИМХО, конечно.

Мне почему-то Laravel очень Rails всегда напоминал. Не фукнционалом, так подходом к экосистеме разработки.

Наверно не почему-то, а из-за их сахарка вроде withComments() или как они там совмещают условия со связями..?

Даже не технологически. Идейно что ли. Они там всё for fun.

Их девиз - разработка в радость. И Rails так же. Они все счастливые всегда и беспечные. ))

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

Если в результате получаются разные сущности - делай две разные таблицы и оставь флажок кто он сейчас в общей таблице users. Вдруг бизнесу понадобится, чтоб пользователь мог поменять свой тип. Например был продавцом, стал покупателем, и наоборот. Тогда тебе нужно будет сохранить старые данные и добавить ему новую связь, переключив флажок в основной таблице профиля Как-то так

Это, получается, им нужен будет разные компонет User? Как это разграничить? Модулями отдельными?

Непонятно как у вас происходит авторизация разных типов пользователей

Это, получается, им нужен будет разные компонет User? Как это разграничить? Модулями отдельными?

User оставь один на всех и профиль оставь один на всех, с общей информацией. А профиль уже вяжи с какой-то сущностью, и там делай индивидуальные поля. Таким образом сможешь вынести это в модуль profile и в нем регулировать эти вопросы. Профиль можешь вязать через user_id, чтоб из пользователя мог отдельно получать данные "продавца" и "покупателя" У тебя везде должно выйти 1 к 1, поэтому из профиля сможешь получать данные через ->hasOne(Customer::class, ['user_id' => 'user_id'])

Кстати, вопрос залу: а вы храните контроллеры и вьюшки в модулях? Не думали что бы этого не делать?..

Кстати, вопрос залу: а вы храните контроллеры и вьюшки в модулях? Не думали что бы этого не делать?..

А смысл тогда модулей?

Это было припасено на второй вопрос. ?

Ну второй тогда в студию)

Модуль - это группировка бизнес-логики, объединённой общей целью. А имеет ли отношение реализация этой логики к ней отношение?..

Контроллеры и вьюшки ближе к реализации, чем к логике.

Хм, тогда чтобы перенести какой то работающий модуль постоянно реализовывать его в другом проекте, интересная логика ?

Да, есть в этом замечании изрядно смысла. Но часто ли ты таскаешь контроллеры и вьюшки без изменения?..

Разные проекты - разная интерфейсная логика.

Да, есть темы. Но не всегда только ими можно обойтись.

Я не настаиваю на своём мнении. Просто обдумываю такой подход последние пару дней. Интересно послушать что думает сообщество по этому поводу.

Кстати, вопрос залу: а вы храните контроллеры и вьюшки в модулях? Не думали что бы этого не делать?..

я стараюсь делать модули такими, чтоб их можно было вынести на отдельный сервер. Без контроллеров это будет сделать сложновато Модули в yii - отдельное приложение

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

я стараюсь делать модули такими, чтоб их можно было вынести на отдельный сервер. Без контроллеров это будет сделать сложновато Модули в yii - отдельное приложение

В этом случае, у тебя действительно модули, как это понимается в канонах. Тут - однозначно они должны быть и ты большой молодец!

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

У нас просто общая бизнес-логика между проектами, а фактическая её реализация очень сильно разнится.

Почему модули, а не библиотеки? Всё просто: конечная реализация бизнес-логики часто бывает неотъемлемой частью бизнес-логики. Например, - обработка уведомления от почтовой системы об отправке или неотправке письма. Это контроллер, раут и т.п.

Почему модули, а не библиотеки? Всё просто: конечная реализация бизнес-логики часто бывает неотъемлемой частью бизнес-логики. Например, - обработка уведомления от почтовой системы об отправке или неотправке письма. Это контроллер, раут и т.п.

это индивидуальные события внутри модуля. Можно унаследоваться и реализовать один метод registerEvents в нужных проектах. Основная часть по общему шаблону

Как вариант, да.

@ExileeD ты шаришь всяко

не видел не одну реализацию по поводу валидации в TransactionScript. все выносят отдельно что бы не нарушать солиды. Но единых правил валидации в ддд нет. Многие бизнес валидацию делают в доменной модели. Для промежуточных вариантов валидации используется Паттерн Снимок. бизнес-сущность защищает свои инварианты и всегда должна находиться в валидном состоянии самая норм статья https://lostechies.com/jimmybogard/2009/02/15/validation-in-a-ddd-world/ по теме

не видел не одну реализацию по поводу валидации в TransactionScript. все выносят отдельно что бы не нарушать солиды. Но единых правил валидации в ддд нет. Многие бизнес валидацию делают в доменной модели. Для промежуточных вариантов валидации используется Паттерн Снимок. бизнес-сущность защищает свои инварианты и всегда должна находиться в валидном состоянии самая норм статья https://lostechies.com/jimmybogard/2009/02/15/validation-in-a-ddd-world/ по теме

Оно того стоит? В плане расходов памяти Мы то одинаково сообщение пользователю вернем, что данные невалидны, или получим error, если валидатор пропустит неучтенные данные

ERROR: S client not available

Оно того стоит? В плане расходов памяти Мы то одинаково сообщение пользователю вернем, что данные невалидны, или получим error, если валидатор пропустит неучтенные данные

счас придет Ad.x скажет что дофига памяти занимают эти все классы. нужно ненужно ддд каждый решает сам в проекте но 2й вопрос не понятен =(

Кстати, вопрос залу: а вы храните контроллеры и вьюшки в модулях? Не думали что бы этого не делать?..

Используем моудли не для того чтобы переиспользовать, а чтобы разделить разные слабо связанные модули бизнес логики в рамках 1 монолитного приложения. Ещё оказалось, что в yii2 нету способа раскидать контроллеры по папкам, кроме как создать модуль.

Используем моудли не для того чтобы переиспользовать, а чтобы разделить разные слабо связанные модули бизнес логики в рамках 1 монолитного приложения. Ещё оказалось, что в yii2 нету способа раскидать контроллеры по папкам, кроме как создать модуль.

можно раскидывать по папкам.

Почему, нельзя?..

Как?

В конфигах приложения указываешь namespace и все контроллеры должны быть в этом неймспейсе

счас придет Ad.x скажет что дофига памяти занимают эти все классы. нужно ненужно ддд каждый решает сам в проекте но 2й вопрос не понятен =(

:D пхписты как и джависты слишком упарываются в академимческий ооп в последние годы. Учитывая жизненный цикол приложения на пхп выглядит это как-то нелепо, да и заметно сказывается на производительсноти :)

Слова не мальчика, но мужа!

Джавистам это необходимо.

Как?

https://github.com/qiansen1386/yii2/commit/eb8296f2bb18c4f68e442f22879213f4e58b7e85

:D пхписты как и джависты слишком упарываются в академимческий ооп в последние годы. Учитывая жизненный цикол приложения на пхп выглядит это как-то нелепо, да и заметно сказывается на производительсноти :)

ну с тобой то понятно. крудам это все ненужно

А иначе как бабло зарабатывать? Надо упарываться по всяким продвинутым техникам. Тогда и ценник можно зарядить норм!

:D пхписты как и джависты слишком упарываются в академимческий ооп в последние годы. Учитывая жизненный цикол приложения на пхп выглядит это как-то нелепо, да и заметно сказывается на производительсноти :)

можно примеры %)

Джавистам это необходимо.

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

Выпьем за питон!

за упокой?! :D

Выпьем за питон!

Вздрогнем! За упокой его.

Зато он политкорректный

Да это уже старая тема. Очень давно эта конетель. Самое громкое было с roslyn. Когда отказались от whitelist/blacklist

https://github.com/dotnet/roslyn/pull/3507/

Нашёл )

Самый любимы комментарий про whitespace

Надо на табы переходить. ?

Питон мог захватить мир, но был побеждён UTF. ¯\_(ツ)_/¯

:D

никто не в курсе. если взять серт от клаудфлары но не проксить через нее, серту пиздец не настанет?

народ, может я конечно и чего-то не знаю, но как переопределить или отключить less файл

вот он мне всю малину для печати страницы портит