Ибо мало толку тогда чтобы делать для себя выводы и расширять кругозор

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

ну то есть знать нюансы работы JVM если ты вдруг решил пописать на Java для расширения кругозора не надо - достаточно понимать что оно есть и что это такое.

пойду какой-нибудь язык поучу

У тебя есть ровно два часа

ай не, я писал на нем пару лет назад

ну вот когда гугл ангуляр на дарт переписывал)

А в qml, можно части UI выносить в функции и переиспольщовать или генерировать UI на лету?

И как же это приходит? Это же что то xml подобное

К примеру тебе с сервера приходит конфиг описывающий UI и тебе нужно его создать

Понятно, я конечно qml не знаю, но все видимые мной форматы описания UI в xml были сильно ограничены. Классно UI делать в коде, если язык выразительный и позволяет создавать красивые eDSL. Флаттер/дарт к этому стремимся, хотя бы выбрасыванием new (но есть над чем работать) Плюс у флаттера классно, что они выбрали архитектуру как React(js)

Понятно, я конечно qml не знаю, но все видимые мной форматы описания UI в xml были сильно ограничены. Классно UI делать в коде, если язык выразительный и позволяет создавать красивые eDSL. Флаттер/дарт к этому стремимся, хотя бы выбрасыванием new (но есть над чем работать) Плюс у флаттера классно, что они выбрали архитектуру как React(js)

qml немного отличается от xml

совсем чуть-чуть))

К примеру тебе с сервера приходит конфиг описывающий UI и тебе нужно его создать

Зачастую это просто симптом бэкенда-самодура

Отдавайте api, фронт без вас разберётся как рисовать и что генерить)

Это кстати про все фронтенды сейчас, без деления на платформы

К примеру тебе с сервера приходит конфиг описывающий UI и тебе нужно его создать

Привет web 90ых

...щас по ходу весь xml словами опишет

Отдавайте api, фронт без вас разберётся как рисовать и что генерить)

Это был пример в вакууме. А вот из реального - делал генерацию UI для настроек индикатора биржевых графиков. Вот там реально у каждого индикатора был разный набор настроек. Вот тут пришлось пое#### с фреймворком, где UI декларативный. На каком нибудь React, я бы сгенер без проблем, рекурсивной функцией.

Ну лан

Убедил)

Является ли коллекция репозиторием?

Является ли коллекция репозиторием?

В моем понимании нет

Является ли коллекция репозиторием?

хранит? да отдает? да значит да. чем она от ин мемори базы отличается?

в смысле от ин мемори базы? Это же отдельный компонент. А я про паттерн

В моем понимании нет

какие различия?

Является ли коллекция репозиторием?

Репозиторий это коллекция, которая содержит корни агрегатов

корни агрегатов... Это как?

это тебе в ddd, сынок

в смысле от ин мемори базы? Это же отдельный компонент. А я про паттерн

я имею в виду не с точки зрения реализации, а с точки зрения функционала.

ну я знаю что такое агрегат

aggregate root ведь

корни агрегатов... Это как?

Гугли aggregate root

мне непонятен контекст "корень агрегата"

а, окей

спасибо

какие различия?

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

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

инфраструктура - понятие расстяжимое. Про какую инфраструктуру речь?

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

так тебе ж по хорошему не важно "как оно там под капотом". репозиторий и дает тебе доступ к некой инфраструктуре как к коллекции.

инфраструктура - понятие расстяжимое. Про какую инфраструктуру речь?

я под инрфаструктуорйо понимаю "реальны мир" - интерфейс, бд, сеть, юзера и т.д. Но в данном случае я про хранение данных именно

так тебе ж по хорошему не важно "как оно там под капотом". репозиторий и дает тебе доступ к некой инфраструктуре как к коллекции.

да я понял уже что ты прав был) сначала просто меня сбило что репа персистенцом занимается, а потом понля что в случае коллекции его нет)

Я извиняюсь за оффтоп, речь конкретно про laravel. Там на уровне фреймворка реализованы коллекции. Некоторые добавляют еще и репозитории поверх них (хотя коллекции там вроде как являются репозиториями). Мое мнение - это делают ради того, что бы не привязываться к деталям фреймворка

Да часто видел такое в ларе, репозитории возвращают коллекции

Угу. Получается мы можем в любой момент поменять коллекции eloquent на doctrine entity, а доменной логике будет на это в принципе пофиг, т.к. все изменения нивелируются на уровне репозитория

Да часто видел такое в ларе, репозитории возвращают коллекции

так а как еще вернуть выборку нескольких обхектов?

можно массив конечно но это такое...

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

просто в джаве есть удобные всякие штуки, а в пыхе массивы возвращать это зашквар

так а как еще вернуть выборку нескольких обхектов?

Тут еще вопрос, а зачем вам несколько агрегатов за раз?)

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

Если на запись, то возникает вопрос про границы

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

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

Тут еще вопрос, а зачем вам несколько агрегатов за раз?)

а как же обычная реализация REST, GET должен вернуть все объекты

а как же обычная реализация REST, GET должен вернуть все объекты

1. s/REST/json api 2. GET это чтение, зачем вам write model для чтения?

а вот если допустим мне нужно выбрать 10 учеников со школы и перевести их в другую...то как тут быть? типо сначала делаешь выборку обычнм запросом а потом уже из памяти создаешь сущности и меняешь их?

допустим отобрать нужно тех у кого имя и фамилия отличаются на а

ERROR: S client not available

1. s/REST/json api 2. GET это чтение, зачем вам write model для чтения?

что нужно загуглить чтобы понять что ты написал?

а вот если допустим мне нужно выбрать 10 учеников со школы и перевести их в другую...то как тут быть? типо сначала делаешь выборку обычнм запросом а потом уже из памяти создаешь сущности и меняешь их?

Если из 10 учеников одного ты не смог перевести, то остальных тоже не надо?

что нужно загуглить чтобы понять что ты написал?

sapi, rest api, json api

я полагаю

Если из 10 учеников одного ты не смог перевести, то остальных тоже не надо?

надо

надо

Тогда у тебя 10 параллельных транзакций получается

я полагаю

не это мне не помогло(

что нужно загуглить чтобы понять что ты написал?

Первый пункт это (s)ed https://unix.stackexchange.com/questions/159367/using-sed-to-find-and-replace

стало еще непонятнее ?

причем тут find & replace

Да часто видел такое в ларе, репозитории возвращают коллекции

репозиторий это и есть коллекция по сути, логично что ты можешь "срез" оной получить

на unix...

щас может накидает ссылок и разберемся

он таким образом тонко выразил мысль что "REST небывает, это миф, юзай json api и не еби голову"

Ну блин, replace подстроки в строке s/string to replace/string to replace with

репозиторий это и есть коллекция по сути, логично что ты можешь "срез" оной получить

Во. Сергей, можешь сказать, зачем нужен дополнительный слой репозиториев для коллекций в laravel?

а вторая мысль была в том что может не надо сущности доктриновские (которые бизнес логика) юзать во view (формировать из них json-ки). Можно вьюшки в базе херачи, active record рядом поставить и т.д

Во. Сергей, можешь сказать, зачем нужен дополнительный слой репозиториев для коллекций в laravel?

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

ну короч та же мысль - почему они сервис локатор + регистри фасадом называют

Короче я понял, пойду вьюхи в базу пихать

ну и еще думаю найдется десяток "паттернов" которые они просто притянули но не понимают

всем спасибо ?

Там же бал правит этот, который некомпетентный "мануфактурщик", который хороший маркетолог и не более

ну и еще думаю найдется десяток "паттернов" которые они просто притянули но не понимают

мне кажется там имеются ввиду не те фасады

фасады в ларе это просто 10 из 10

а фасады для сервисов