Привет всем. Вопрос касательно архитектуры. Интересно ваше мнение.
Какой вариант из нижеприведённых лучше с точки зрения построения большого приложения.
Условие.
Есть некий компонент (виджет) на стороне фронта который применяется во многих страницах.
Естественно его нужно обрабатывать на стороне бэкенда, для этого был создан некий 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()
https://laravel.com/docs/5.2/eloquent-relationships
Polymorphic Relations
posts
id - integer
title - string
body - text
comments
id - integer
post_id - integer
body - text
likes
id - integer
likeable_id - integer
likeable_type - string
posts
id - integer
name - string
videos
id - integer
name - string
tags
id - integer
name - string
taggables
tag_id - integer
taggable_id - integer
taggable_type - string
persons
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 - integer
persons
id - integer
fio - string
индекс
область
город
улица
дом
persons
id - integer
fio - string
city-string
country-string
edu-string
Person -> has many Education
Person -> has many Location
// маневрируешь с локациями как хочешь
Location -> has one City
Location -> has one Region
Location -> has...
adress
str-string
flat-string
floor-strin
я бы сделал примерно так.
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
@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...
?
@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),
]
]
trying to get property of non-object/
но вот такое использование проходит свободно $book->engName['id']
$books = $medicine->all();
$books->with('engName');
'recipe' => (bool) $book->reiCPe
'id' => $book->engName?$book->engName->id:0,
@Big-Shark @jhaoda
помогите плиз)
почему-то говорит что ->toJson() такого метода нет
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: {}
}
}