я все утро краем глаза это наблюдаю

ReadApple() *Apple {} ReadApples() []*Apple {}

во, товарищ Подольский подтянулся

и ощущения, что что-то не понятно, или что-то не получается, нет

он, например, знает, чем DAO от репозитория отличается

а есть ощущение неизбывной боли

а есть ощущение неизбывной боли

в каком месте и от чего?

на самом деле мне сложно переучиваться

в пыхе у нас было все в повалку

в каком месте и от чего?

от того, что у @ruelephant не получается делать, как он привык

$users = UserModel::find(['age'=>21]) foreach($user ...) { $user->sex = UserModel::Male $user->save(); }

он, например, знает, чем DAO от репозитория отличается

а что, кто-то не знает?

я не знаю)

я думал дао это тупо обхект с полями и геттерами сеттерами

без логики

а что, кто-то не знает?

они, например, местами очень похожи. Собственно, до взаимопроникновения. И определить, где в конкретной реализации DAO, а где уже репозиторий для меня, например, бывает сложно.

тут конечно не для гоу - https://habr.com/post/263033/

и это довольно мутная статья

но, вообще, граница там смутная

ну насколько я понял

разница в том что репозиторий работает с коллекциями

а что, кто-то не знает?

насколько мне представляется, репозиторий - это реализация "коллекции" поверх слоя "физических данных", а DAO - это реализация набора интерфейсов/методов для доступа к "физическим данным"

а DAO работает с параметрами

репозиторий ближе к базе, dao ближе к бизнес-логике

для го дао походу больше заказтывает

void delete(String userName);// DAO void removeAccount(Account account); // Репозиторий

в го с коллекциями не оч хорошо

и вот если этот DAO реализует интерфейс доступа, похожий на набор методов работы с коллекцией, становится малопонятно, где кто

угу

но и пофиг же

собственно, примерно да, примерно пофиг. Тут уже больше вопрос "технического пуризма"

те же "паттерны" (в переводе - шаблоны), это набор рекомендаций/устоявшихся практик

т.е. "советы бывалых, которые на ЭТИ грабли уже наступили"

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

в момент реализации совершенно не обязательно знать, под какую главу "Воспоминаний бывалых" подпадает то, что ты делаешь.

если потом другим конечно с этим не работать...

иначе код превращается в адЪ

но бывает приятно сказать "да ты гонишь, никакой это не DAO, это же репозиторий"!)))

а дальше попросят обосновать...

а дальше начнутся сложности)))

http://codehelper.ru/questions/205/new/repository-%D0%B8-dao-%D0%BE%D1%82%D0%BB%D0%B8%D1%87%D0%B8%D1%8F-%D0%BF%D1%80%D0%B5%D0%B8%D0%BC%D1%83%D1%89%D0%B5%D1%81%D1%82%D0%B2%D0%B0-%D0%BD%D0%B5%D0%B4%D0%BE%D1%81%D1%82%D0%B0%D1%82%D0%BA%D0%B8

http://qaru.site/questions/7209/what-is-the-difference-between-dao-and-repository-patterns

ну пару ссылок

ну насколько я понял

Гораздо проще все. Условно у тебя есть type Entity struct. При подходе Repository, у тебя будет EntityRepository, в котором будут методы Save(Entity), GetAll() []Entity, При подходе DAO, у структуры Entity будут методы Save(), All()

с вашего объяснения можно подумать что разница только в именовании методов :)

не, он намекает на то, что DAO прикручивается к бизнес-сущности, а репозиторий - отдельная сущность сбоку

с вашего объяснения можно подумать что разница только в именовании методов :)

entity := Entity{Field1, FIeld2} entity.Save() И entity := Entity{FIeld1, FIeld2} entityRepository.Save(entity) Ну совсем уже на пальцах

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

насколько я понял у @CheshireKot объяснение ближе к репозиторию таки

только я не уверен, что тов. Никитенко прям стопроцентно прав

ну то что выше мы проговаривали

если оталкивался от рассуждений @mykytanikitenko

если конечно он не имел ввиду EntityDAO сущность, а не оригинальную модель

собственно, не вижу препятствий реализации DAO в виде отдельной сущности.

если конечно он не имел ввиду EntityDAO сущность, а не оригинальную модель

вот это похоже на правду

DTO для го не подхоодит На дотнете, например, мы определяем класс с виртуальными полями. Даже фреймворк, например, EF, создает через рефлексию в рантайме новый объект-прокси, который наследует от оригинального класса и икапсулирует доступ ко всем этим полям, очень много магии происходит. В го такое почти нереально сделать

просто применительно к Go идея прикрутить DAO к самой сущности достаточно мутная

собственно, я бы скорее склонялся в сторону type CRUDer interface{ Create() Read() Update() Delete() }

и рядом обертки над типом сущности

т.е. Entity отдельно, EntityDAO отдельно

собственно, я бы скорее склонялся в сторону type CRUDer interface{ Create() Read() Update() Delete() }

Называется Generic Repository, это плохой паттерн :)

другое дело, что EntityDAO вполне может выглядеть как type EntityDAO struct { Entity } или даже type EntityDAO Entity

другое дело, что EntityDAO вполне может выглядеть как type EntityDAO struct { Entity } или даже type EntityDAO Entity

Ага, туда еще подключение к бд передай

Называется Generic Repository, это плохой паттерн :)

собственно, в Go есть таки специфика, которая достаточно существенно может отличать его от полно-классических-ООП-языков, для которых эти самые паттерны и рожали

Ага, туда еще подключение к бд передай

собственно, достаточно спорное предложение. sql.DB, емнип, вполне себе пул, и оно при констракте вполне может подтянуться само, например

дело в том, что система типов Go - достаточно простая, до примитивности, вещь

и многие идеи, которые отлично ложатся на логику Java и прочих "Скал", в чистом виде в Go приводят к форменному бреду

ERROR: S client not available

собственно, достаточно спорное предложение. sql.DB, емнип, вполне себе пул, и оно при констракте вполне может подтянуться само, например

В го нет конструкторов, если не использовать DI контейнер, то непонятно откуда оно само подтянется

привет

собственно, достаточно спорное предложение. sql.DB, емнип, вполне себе пул, и оно при констракте вполне может подтянуться само, например

само, это как?

delve не могу установить в vs code

помогите

какой то жесть

mac

помогите

могу только помолиться за тебя

если мы имеем type Entity struct, определяя идею DAO как "прикрутить методы CRUD к самой сущности" мы сразу хороним сам подход для Go

могу только помолиться за тебя

чего?

само, это как?

например, взяться откуда-то синглтоноподобного

чего?

инфы ему дай

как он узнает в чем проблема у тебя если он ничего не знает о твоей проблеме

ну вы в vc code дебажите?

я нет

нет

я в goland

там все из коробки работает

теперь еще и dep

ну вы в vc code дебажите?

это секта свидетелей goland

В го нет конструкторов, если не использовать DI контейнер, то непонятно откуда оно само подтянется

ага, в Го нет конструкторов. При этом в нем нету еще классического "наследования", в нем запрещены кросс-импорты, в нем нет дженериков, собственно, в нем и синглтон - вполне нормальная штука, хотя в той же Java его с песнями и плясками как говно-паттерн хоронят уже лет 5

так я тоже хочу)

тока там триал версия

=((

ща качну

так я тоже хочу)

jetbrains.com - там goland есть

уже качаю

тока там триал версия

там есть помесячная подписка, не дорого

ага, в Го нет конструкторов. При этом в нем нету еще классического "наследования", в нем запрещены кросс-импорты, в нем нет дженериков, собственно, в нем и синглтон - вполне нормальная штука, хотя в той же Java его с песнями и плясками как говно-паттерн хоронят уже лет 5

а куда положить какие-нибудь сложные query?

пока мне он денег не приносит не могу платить(

вот xcode фри я бы за него платил по месячно

а куда положить какие-нибудь сложные query?

в методы DAO?