Alex
у меня ajax
Alex
то есть изначально это было написано так что чувак регается, получает токен и потом по этому токену опять идет запрос на сервер, чтобы поулчить Layer
Alex
Я эту бредятину хочу переписать чтобы LayerController@show сразу отдавался при регистрации
Alex
И в принципе работает но смущает копипаста
Alex
То есть если я в LayerController@show что то поменяю надо будет не забыть ручками в RegisterController тоже актуализовать
Pavel
Вынеси логику из этих методов с отдельный сервис?
Pavel
Или в модель пользователя
Alex
Ну это жестоко чот
Pavel
СОЛИДно жеж
Alex
абстракция на абстракции сидит
Alex
я думаю в register вызвать этот экшен layer, потом просто с ним поработать как с json потом вернуть уже юзеру
Alex
но меня смущает что надо инъекцию LayerController тогда делать в Register
Станислав
d
Dmitry
но меня смущает что надо инъекцию LayerController тогда делать в Register
Инъекцию контроллера? Ну и каша у тебя в голове
Alex
Как вызвать экшен другого контроллера?
Alex
Вариант с тем чтобы создавать отдельный сервис, в который будут стукаться оба контроллера мне кажется еще более худшим вариантом
Dmitry
Dmitry
Провайдер
:) нет это совсем из другой оперы. Сервис это класс или модуль который реализует какой то кусок твоей бизнес логики. И вся бизнес логика должна быть в сервисах
Alex
Есть LayerController, который отдает слои пользователя
Alex
Есть RegistrationController, который его регистрирует
Alex
Я хочу чтобы при регистрации отдавались слои пользователя
Alex
Как это реализовать?
Alex
Категории пользовательские
Alex
Не суть, модель, которая привязана к пользователю
Dmitry
Категории пользовательские
задача контроллера принять запрос, как то его обработать, и отдать ответ.
все данные ты получаешь в котроллере и отдаешь с ответом. Этому каждый контроллер уникален, и его нет смысла куда то ижектить. Скинь код этих 2х контроллеров так понятенее будет что ты пытаешься сделать
Alex
class LayerController extends Controller
{
public function show(Layer $layer) {
$markers = $layer->markers('clean');
$layer = $layer->only(['id','name']);
return response()->json(array(
'layer' => $layer,
'markers' => $markers,
));
}
Alex
class RegisterController extends Controller
{
$layers = $user->layers('clean');
$markers = $layers->first()->markers('clean');
return response()->json([
'success'=> true,
'id'=> $user['id'],
'name' => $user['name'],
'layers' => $layers,
'markers' => $markers,
])->header('Authorization', "Bearer ".$token);
Dmitry
class RegisterController extends Controller
{
$layers = $user->layers('clean');
$markers = $layers->first()->markers('clean');
return response()->json([
'success'=> true,
'id'=> $user['id'],
'name' => $user['name'],
'layers' => $layers,
'markers' => $markers,
])->header('Authorization', "Bearer ".$token);
так у тебя же способ получения разный в этих методах
Alex
В общем, есть три модели: User, Layer и Marker. Layer принадлежит User, Marker принадлежит Layer. У каждого свой контроллер на просмотр, создание и тд
Alex
Я хочу при регистрации User создать ему дефолтный Layer с дефолтными Marker
Alex
Для этого мне надо вызвать экшены create у LayerController и MarkerController соответственно. Причем сделать это из RegistrationController
Alex
Мне кажется достаточно типовая задача
Aleksey Y.
Делай через события
Alex
Сейчас я ее решил тем что заинъектил LayerController в RegistartionController
class RegisterController extends Controller
{
public function __construct(LayerController $layerCtrl, Faker $faker)
{
$this->layerCtrl = $layerCtrl;
Alex
И обращаюсь через $this->layerCtrl->create...
Alex
и меня это смущает, но я не могу понять как по-другому
Dmitry
И обращаюсь через $this->layerCtrl->create...
это полный бред. А если в запросе не будет нужных данных? как у тебя он создастся?
Alex
Через события тоже не совсем понятно, потому что я же хочу при запросе на RegistrationController сразу отдать данные и с Layer и с Marker. То есть я предполагаю что мне надо изнутри RegistrationController что то сделать
Alex
это полный бред. А если в запросе не будет нужных данных? как у тебя он создастся?
Блин. При регистрации не может не быть нуджных данных потому что их я задаю сам, это дефолтный слой
Alex
Естественно при стороннем обращении к LayerController есть валидация и тд
Aleksey Y.
Dmitry
Блин. При регистрации не может не быть нуджных данных потому что их я задаю сам, это дефолтный слой
а контроллер откуда данные берет? ты будешь подделывать запрос?
Alex
Бинго!
Alex
$myRequest = new Request([
'name' => 'Главная',
'user_id' => $user['id'],
'icon' => 'pin',
]);
$this->layerCtrl->create($myRequest);
Dmitry
$myRequest = new Request([
'name' => 'Главная',
'user_id' => $user['id'],
'icon' => 'pin',
]);
$this->layerCtrl->create($myRequest);
ты когда нибудь пробовал разработку через тестирование?
Alex
Нет
Dmitry
Нет
вот зря, смотри как у тебя должен работать котроллер регистрации (примерно)
class Register
function registerUser(Request $request, UserRegisterService $service){
$responce['result'] = true;
try{
$user = $service->registerUser($request);
$responce['user'] = $user;
}catch(Exeption $e){
}
return $responce;
}
Dmitry
все, больше тут ничего не должно быть
Alex
Ок, в UserRegisterService как вызвать экшен LayerController?
Dmitry
Ок, в UserRegisterService как вызвать экшен LayerController?
в сервисе не надо вызывать контролле там просто создаешь пользователя
class UserRegisterService
$user = User::create(...);
if(!$user){
throw Exeption
}
$loyer = $user->loyer()->create(...);
$loyer ->markers()->create(...);
return $user ;
Alex
Можно решить событиями если мне просто нужно уведомть LayerController. Но если мне нужно получить результат экшена? Ребята предлагают написать отдельный провайдер, в который и LayerController и RegistrationController будут стукаться но это вообще жесть
Dmitry
Можно решить событиями если мне просто нужно уведомть LayerController. Но если мне нужно получить результат экшена? Ребята предлагают написать отдельный провайдер, в который и LayerController и RegistrationController будут стукаться но это вообще жесть
запомни, контроллер вызывает только запрос. Все больше никто его вызвать не может
Evgenii
Всем привет. я только начинаю знакомство с Laravel и меня несколько смутила двойственная ситуация с внешними ключами. подскажите пожалуйста мне.
В документации говорится, что можно делать, а можно и нет, просто сказав в eloquent что имеются такие-то отношения между моделями. Но зачем это? Чтобы самому за целостностью данных следить?( Высокоуровнево абстрагироваться от бд? О_о
Какие best practices приняты в Laravel?
Дима
Всем привет. я только начинаю знакомство с Laravel и меня несколько смутила двойственная ситуация с внешними ключами. подскажите пожалуйста мне.
В документации говорится, что можно делать, а можно и нет, просто сказав в eloquent что имеются такие-то отношения между моделями. Но зачем это? Чтобы самому за целостностью данных следить?( Высокоуровнево абстрагироваться от бд? О_о
Какие best practices приняты в Laravel?
Отношения очень просты в освоении. Но лучше уже понимать какие бывают типы отношений и как создавать и получать данные у связанных таблиц
Дима
Я принципиально не буду писать ответ, все есть в доках
Evgenii
я не про получение, а скорее про удаление и мертвые записи. если не ввести внешние ключи и их ограничения - я подозреваю, что мы можем получить ряд "мертвых" записей, при удалении некоторых записей, связанных с другими
Evgenii
наверное если не генерить ключи - надо как-то в логике модели это дело обрабатывать
Samat
наверное если не генерить ключи - надо как-то в логике модели это дело обрабатывать
да, но лучше получить конкретную ошибку с бд, чем потом вкуривать по полчаса, что произошло
Evgenii
http://www.diegocaprioli.com/laravel-migrations-write-those-foreign-keys-from-the-start/#I_see_dead_records8230 вот примерно на чем основывается мое беспокойство.
лично мне кажется что лучше сгенерить внешние ключи и прописать все эти действия сразу. такие например как каскадное удаление, или запрещение удаления, если есть связанные сущности.
но зачем-то же в архитектуре laravel сделано так что можно по одному и по второму пути пойти. как в сообществе laravel считается хорошим тоном работать?
Anton
Евгений, это сильно зависит от принятых соглашений, никаких бест практик тут нет.
Evgenii
Евгений, это сильно зависит от принятых соглашений, никаких бест практик тут нет.
насколько я успел посмотреть по гитхабу проекты разных людей - тоже никакой единственной картины нет. кто-то делает так, кто-то иначе. думаю каждый просто решает, где манипулировать некоторой частью логики, отдать на откуп самой бд или вынести в приложение.
Dmitry
насколько я успел посмотреть по гитхабу проекты разных людей - тоже никакой единственной картины нет. кто-то делает так, кто-то иначе. думаю каждый просто решает, где манипулировать некоторой частью логики, отдать на откуп самой бд или вынести в приложение.
если у тебя простая логика типа есть основная запись, есть связанно, удалили основную, удалилась связанная, то это можно базе отдать. А вот если что то типа "Нельзя удалять пользователя у которого 3 задания в процессе работы, и начаты не позднее 3х месяцев назад" то это уже приложению надо отдавать.
Evgenii
если у тебя простая логика типа есть основная запись, есть связанно, удалили основную, удалилась связанная, то это можно базе отдать. А вот если что то типа "Нельзя удалять пользователя у которого 3 задания в процессе работы, и начаты не позднее 3х месяцев назад" то это уже приложению надо отдавать.
а если у меня при такой сложной логике внешний ключ таки иметься будет, а логику я повешу на какой-то eventListener событий бд(не знаю есть ли он в laravel и как правильно называется, но логично предположить, что такой имеется) и там всё это дело проверю - так тоже будет норм?
Evgenii
вы извините, если я туплю. я laravel только начал смотреть, а опыт разработки у меня из таких страшных областей пхп, которые не очень сочетаются с концепциями нормальных пхп фрэймворков
Dmitry
а если у меня при такой сложной логике внешний ключ таки иметься будет, а логику я повешу на какой-то eventListener событий бд(не знаю есть ли он в laravel и как правильно называется, но логично предположить, что такой имеется) и там всё это дело проверю - так тоже будет норм?
наверное, но я не люблю события :) это скользкая дорожка
Evgenii
наверное, но я не люблю события :) это скользкая дорожка
а не покажешь какой-нибудь пример как такая логика обрабатывается не на событиях, а в самом eloquent? может ссылочку дашь где пример посмотреть, чтобы я понял разницу
Samat
а не покажешь какой-нибудь пример как такая логика обрабатывается не на событиях, а в самом eloquent? может ссылочку дашь где пример посмотреть, чтобы я понял разницу
по примеру Дмитрия (про 3 месяца): вешаешь удаление на какой-нибудь метод в контроллере. в контроллере запрос на проверку даты. если прошел, то $model->delete(), нет - response с ошибкой
Dmitry
а не покажешь какой-нибудь пример как такая логика обрабатывается не на событиях, а в самом eloquent? может ссылочку дашь где пример посмотреть, чтобы я понял разницу
лучше использовать сервис для удаления, а не вызывать метод удалить напрямую у модели. Это ж странно когда объет может сам себя удалить :)
Dmitry
но в контексте AR так и придется делать. Но если это сделать в сервисе, то код станет гибче
Evgenii
так-с, ну примерно понял, да. спасибо👍