Привет всем. Вопрос касательно архитектуры. Интересно ваше мнение.
Какой вариант из нижеприведённых лучше с точки зрения построения большого приложения.
Условие.
Есть некий компонент (виджет) на стороне фронта который применяется во многих страницах.
Естественно его нужно обрабатывать на стороне бэкенда, для этого был создан некий service myWidgetGenerator
который занимается построением ответа для этого виджета.
И вот подходимк моменту когда на каждом контроллере нужно для разных моделей передавать этому генератору различные параметры в итоге контроллер разрастается вот к такому виду.
Вариант Номер 1
http://laravel.io/bin/yGm63
Второй вариант запихать генеротор в сервис провайдер и тогда сервисный класс будет состоять из двух классов:
непосредственно сам Generator и GeneratorRepository
где GeneratorRepository - Набор свойств и конструктор
а Generator - набор методов с параметрами для построения виджета для разных моделей:
http://laravel.io/bin/52DN8
И сам контроллер тогда принимает вот такой вид:
http://laravel.io/bin/kW5aP
@slider23
Нет больше одного раза не буду.
Например у второго варианта есть плюсы:
Если когда-нибудь решу передалать что-нибудь в этом генераторе,
Не придётся бегать по всем контроллерам и менять.
Достаточно будет открыть один файлик Generator
И унего изменить все методы
renderProviderBlanks() renderSomethingElse....
Зато у первого удобней навигация.
Сразу наглядно что куда передаётся,
Ctrl+click перелетаешь в файлик с реализацией метода render()
и всё видишь.
Во втором же варианте придётся
Залазить в AppServiceProvider
там лезть в генератор, потом смотреть от кого он унаследован и потом уже увидешь реализацию render()
posts
id - integer
title - string
body - text
comments
id - integer
post_id - integer
body - text
likes
id - integer
likeable_id - integer
likeable_type - stringposts
id - integer
name - string
videos
id - integer
name - string
tags
id - integer
name - string
taggables
tag_id - integer
taggable_id - integer
taggable_type - stringpersons
id - integer
fio - string
city_id - integer
...
edu_id - integer
cityes
id - integer
name - string
sort - integer
...
edus
id - integer
name - string
sort - integer
и будет так
```
persons
id - integer
fio - string
справочник_id - integer
справочники
id - integer
name - string
sort - integer
type-text```
persons
id - integer
fio - string
справочник_города_id - integer
справочник_образование_id - integer
справочник_организация_id - integer
справочники
id - integer
name - string
sort - integer
type - stringсправочник_города_id - integer
справочник_образование_id - integer
справочник_организация_id - integerGraduation has one Location
```
persons
id - integer
fio - string
индекс
область
город
улица
домpersons
id - integer
fio - string
city-string
country-string
edu-stringPerson -> has many Education
Person -> has many Location
// маневрируешь с локациями как хочешь
Location -> has one City
Location -> has one Region
Location -> has...это утверждение не верно
я бы сделал примерно так.
Person -> has many Education
Person -> has many Location
// маневрируешь с локациями как хочешь
Location -> has one City
Location -> has one Region
Location -> has...@D3-FC
Привет всем. Вопрос касательно архитектуры. Интересно ваше мнение.
Какой вариант из нижеприведённых лучше с точки зрения построения большого приложения.
Условие.
Есть некий компонент (виджет) на стороне фронта который применяется во многих страницах.
Естественно его нужно обрабатывать на стороне бэкенда, для этого был создан некий service myWidgetGenerator
который занимается построением ответа для этого виджета.
И вот подходимк моменту когда на каждом контроллере нужно для разных моделей передавать этому генератору различные параметры в итоге контроллер разрастается вот к такому виду.
Вариант Номер 1
http://laravel.io/bin/yGm63
Второй вариант запихать генеротор в сервис провайдер и тогда сервисный класс будет состоять из двух классов:
непосредственно сам Generator и GeneratorRepository
где GeneratorRepository - Набор свойств и конструктор
а Generator - набор методов с параметрами для построения виджета для разных моделей:
http://laravel.io/bin/52DN8
И сам контроллер тогда принимает вот такой вид:
http://laravel.io/bin/kW5aP
@symbios-zi
легче будет менять сущность в будущем
Person -> has many Location в этой связи можно хранить еще и период времени, когда там человек жил
persons
id - integer
fio - string
территория
организация
должность
категория работника
образование
справочник_территорий
id - integer
name - string
sort - integer
справочник_организаций
id - integer
name - string
sort - integer
и такиеже остальные справочникинапример мне нужно будет выбрать всех персон у которых среднее образование
persons
id - integer
fio - string
территория_id - integer
организация_id - integer
должность_id - integer
категория работника_id - integer
образование_id - integer
справочник_территорий
id - integer
name - string
sort - integer
type - enum(территория, организация, должность, категория работника, образование)Например у второго варианта есть плюсы:
Если когда-нибудь решу передалать что-нибудь в этом генераторе, Не придётся бегать по всем контроллерам и менять. Достаточно будет открыть один файлик Generator И унего изменить все методы renderProviderBlanks() renderSomethingElse....
Зато у первого удобней навигация. Сразу наглядно что куда передаётся, Ctrl+click перелетаешь в файлик с реализацией метода render()
и всё видишь.
Во втором же варианте придётся Залазить в AppServiceProvider там лезть в генератор, потом смотреть от кого он унаследован и потом уже увидешь реализацию render() вот в этом то и заключается дилема
и там и там и плюсы и минусы @symbios-zi
Но если у этой модели есть отношение например $providerBank->medicines
@Big-Shark
привет. ты в своё время советовал использовать фрактал.
Вот вытекающий вопрос.
Ты наверняка знаешь про мутаторы и аксессоры.
Дак вот. Не проще ли все необходимые поля заготавливать в модели используя getAtttribute и поумолчанию все полля делать hidden
привязывая их через appends
делать hidden - для того чтобы избедать излишней работы не нужных методов, когда они не нужны и контролировать выходные данные
а конкретно в контроллере для выбора нужных полей делать
makeVisible()
Есть Медикамент, у него есть параметры различного рода:
name, dose, type, dose_number, divisibility_type
Очень часто при работе в разных контроллерах необходимо обращаться к модели Medicine
и получать несуществующий атрибут full_name
который является суммарнной строкой от
name, dose, type, dose_number, divisibility_type
привязывать к выдаче через фрактал
TestInsertModel::insert($insert);. Как в сгенерированный запрос добавить команду?
ON DUPLICATE KEY... ?
там же и вести контроль ролей
Если агент return $this->infoForAgent
Если гость return $this->infoForGuest
}
@Big-Shark Есть ещё вариант делать так
$model->renderResponseData
renderResponseData() {
foreach collection
stats => $repo->getStats()
somth => $repoGetSmth()
}
значит придётся всёравно делать свою прослойку или сервис, тоесть по сути пилить то что уже напилено во фрактале
Выносить в сервис и потом сервис вызывать уже через сервис провайдер в контроллере
Или же в репозиторий к модели пихать и вызывать методом перед отправкой?
$resource = new Collection($books, function(array $book) {
return [
'id' => (int) $book['id'],
'title' => $book['title'],
'year' => (int) $book['yr'],
'author' => [
'name' => $book['author_name'],
'email' => $book['author_email'],
],
'links' => [
[
'rel' => 'self',
'uri' => '/books/'.$book['id'],
]
]
];
});Есть ли инструкция где-нибудь?
[
'referals'=>[
'myCustomText'=>'траляля',
'referalsData'=>$user->referals,
'someVirtutalReferals'=>$user->myVirtualReferal,
'validatedReferals'=>$userRepo->validatedRefarals(),
]
] [
'referals'=>[
'myCustomText'=>'траляля',
'validatedReferals'=>$userRepo->validatedRefarals($user->referals),
]
]вот пытаюсь но не пойму чем плохо использовать уже готовый с фасадами сервис контроллер того же самого fractal-а
если не сложно пару слов. почему не кажется
trying to get property of non-object/
но вот такое использование проходит свободно $book->engName['id']
'recipe' => (bool) $book->reiCPe
'id' => $book->engName?$book->engName->id:0,
@Big-Shark @jhaoda
помогите плиз)
почему-то говорит что ->toJson() такого метода нет
$resource = new Collection($providerBlanks, new ProviderBlankTransformer());
return $fractal->createData($resource)->toArray();
вот так вызываю
if (is_array($items) || $items instanceof \Illuminate\Support\Collection) {
$resource = new \League\Fractal\Resource\Collection($items, $transformer);
} else {
$resource = new \League\Fractal\Resource\Item($items, $transformer);
}require __DIR__ . '/vendor/autoload.php';
error_reporting(E_ALL);
$classes = [];
$functions = [];
$declared = array_merge(get_declared_traits(), get_declared_interfaces(), get_declared_classes());
foreach ($declared as $class) {
$reflection = new ReflectionClass($class);
if ($reflection->getExtensionName() === 'PHPQt5') {
$classes[] = $class;
}
}
foreach (get_defined_functions()['internal'] as $function) {
$reflection = new ReflectionFunction($function);
if ($reflection->getExtensionName() === 'PHPQt5') {
$functions[] = $function;
}
}
$generator = new Z\IdeStubGenerator\Strategy\PSR0();
$generator->setBaseDir(__DIR__ . '/stubs/');
$generator->setClasses($classes);
$generator->setFunctions($functions);
$generator->generate();
Посмотрел, да и не очень внял...
Вот подскажите, каким образом лучше организовать структуру проекта для бота? Там все строится на ивентах по сути, поэтому не знаю MVC паттерн каким-то боком используем при этом или надо организовывать по другому?
P.S. Писать собираюсь на Ноде, но не думаю что это существенно
@Big-Shark
А как убрать 'data' namespace у выдачи фрактала.
в доке сказано использовать другой сериализатор.
подключаю.
$fractal = $fractal->setSerializer(new ArraySerializer());
никакого эффекта... всёравно data лепит спереди
data: {
id: 1,
children: {
data: {}
}
}