https://habrahabr.ru/post/328156/

Народ, вот я на ларке делаю регистрацию

и я типо полностью переделать хочу на модульную структуру это дело

но без DDD

в общем вопрос философский

но без DDD

DDD это не про репозитории/сущности/сервисы если что

ну

хорошо хорошо

в общем вопрос философский

зачем ты хочешь это сделать?

я если честно не представляяю себе как ты это сделаешь со всякими элоквентами

зачем ты хочешь это сделать?

оч здоровый проект, все в одной куче делать не вариант

попробуй про row data gateway почитать

но хз...

ну орм не панацея да, могу и дата маппер взять

актив рекорд в смысле

короче, суть то не в этом

суть в том что active record для этого не предназначена

вот есть у меня сущность User, есть регистрация\авторизация

это когда у тебя простые data-centric приложения и там кроме data model тебе ничего не надо

как мне это дело разбить

как мне это дело разбить

регистрация - фабрика для юзера. Аутентификация - метод у юзера

типо в контексте сущности Юзер все это делать?

как вообще такой подход называется? Или похожий, почитать

ООП?)

про репозитории

я где-то что-то про репозитории сказал?

тебе они пока не нужны

callable в целом не обязательно

ненавижу телеграм

public function authenticate(string $password, callable $hashPassword) { if (password_verify($this->password, $password) }

повторюсь - если ты не хочешь руками DAO делать или доктрину цеплять - читай про row data gateway

Хорошо, спасибо за наводку

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

public function authenticate(string $password, callable $hashPassword) { if (password_verify($this->password, $password) }

А как же принцип единственной ответственности?

А как же принцип единственной ответственности?

а с ним все хорошо

у меня этот метод в сущности Credentials

а password_hash и password_verify и так абстракции

в целом O/C немного нарушен но это не страшно

если юзать дефолтные значения для password api

регистрация - фабрика для юзера. Аутентификация - метод у юзера

Здесь немного про другое говорится )))

Здесь немного про другое говорится )))

в смысле?) что еще надо?

https://github.com/Ocramius/basic-doctrine-tutorial-2017/blob/feature/registration/basic-tutorial/src/Authentication/Entity/User.php

это тип для ленивых

кто не хочет фабрику выносить в отдельный класс

Я про то, что это не в credentials пихать собираются. А потом у меня появился пользователь с соцсети

Я про то, что это не в credentials пихать собираются. А потом у меня появился пользователь с соцсети

ну так это не User, это просто будет еще один вид кредов

ну и опять же

пока у тебя нет пользователей из соц сети

все ок

Я про user писал, если не в нем, то и коммента нет

Я про user писал, если не в нем, то и коммента нет

а почему не в юзере?)

ну то есть вот у тебя на данный момент нет ничего по поводу того что авторизовывать надо пользователей из соц сетей

более того, там и процесс аутентификации будет несколько иным

ты никаких "секретов" проверять не будешь

ты просто по идентити достанешь пользователя

и все

тут уже спрос с коллекции юзеров

а почему не в юзере?)

Он какое отношение к логину имеет? Потом соц сети появятся, потом логин через sms или ещё че

Он какое отношение к логину имеет? Потом соц сети появятся, потом логин через sms или ещё че

ну ты кого логинишь? юзера или квадрат?)

ты просто по идентити достанешь пользователя

Так в коде верификация есть, это не просто "достаешь"

"As a user I should be able to login in order to secure my data"

user .... login

ну ты кого логинишь? юзера или квадрат?)

Я ж писал - прямоугольник )))

Так в коде верификация есть, это не просто "достаешь"

какая верификация?

когда ты логинишься через соц сеть всю верефикацию за тебя сделает внешний сервис. Тебе надо будет только достать юзера

password_verify - это чаю просто попить решили?

это будет другая стратегия ПЕРЕД юзером

ERROR: S client not available

password_verify - это чаю просто попить решили?

это часть процесса аутентификации

когда ты логинишься из соц сети, аутентификация происходит не у тебя

http -> login strategy -?> user->authenticate если надо по стратегии

если у тебя соц сети - то остановишься на login strategy

и дальше не пойдешь

что не так?

да и потом, какя еще логика может быть в классе User кроме как не управление своими кредами?)

апдейт профайла разве что

по сути управление кредами это часть управления профилем пользователя

Пользователю плевать как его аутентифицируют, у тебя один и тот же класс может в десятке мест использоваться и в каждом будет своя аутентификация

Пользователю плевать как его аутентифицируют, у тебя один и тот же класс может в десятке мест использоваться и в каждом будет своя аутентификация

нет не может

это уже будет нарушать SRP

Легко

у тебя есть класс User

и есть только одна роль чуваков которые пользуются этим профилем

этот класс должен использоваться строго в одном контексте

Вот как раз не будет, т.к. эта ответственность будет за пределами user находится

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

Вот как раз не будет, т.к. эта ответственность будет за пределами user находится

как ты определяешь зону ответственности без контекста?

на глазок?

соблюдает код SRP или нет можно сказать только хорошо зная контекст

Здесь и без него понятно

объясни)

Если только user не занимается только аутентификацией

ну то есть я могу тебе предложить контекст в котором наличие метода authenticate у User будет как соблюдать SRP так и нарушать

Если только user не занимается только аутентификацией

так он и не занимается. Самую важную штуку - проверку того что пароль введет корректно, берет на себя password_verify

или например... changePassword ты куда запихнешь?

в юзера?

По порядку

давай на примере changePassword

public function changePassword(string $oldPassword, string $newPassword);

где это должно лежать?