вот что ты несёшь? это был просто пример, показывающий общий подход к реализации репозитория. какая разница какой там сайт?

это не реализация репозитория. Это чушь и говнокод

коллекция - это вполне себе корректный термин в программировании

ну тоесть репозитории в программировании можно представить ввиде массива и мапы?

"действующий как" - это не коллекция, это "представим как будто это коллекция", а что под капотом нас не интересует

я не согласен с утверждением Павла про CRUD в принципе, это весь мой поинт коллекция - это не круд, если не притягивать за уши

просто файлик, который почему-то зовётся *repository

это не реализация репозитория. Это чушь и говнокод

по моему ты гонишь

по моему ты гонишь

тебе явно виднее :)

я не согласен с утверждением Павла про CRUD в принципе, это весь мой поинт коллекция - это не круд, если не притягивать за уши

про crud, как я понял, он вообще не про репозиторий говорил

репозиторий может инкапсулировать как и массив, так и мапу

так и обращения к БД

абстракция, определяющая апи базы. В ООП - в виде интерфейсов соотв.

нет, апи базы - CRUD операции над сущностями

про crud, как я понял, он вообще не про репозиторий говорил

вот, на чем я основываюсь это определение репозитория от Павла

"действующий как" - это не коллекция, это "представим как будто это коллекция", а что под капотом нас не интересует

Ну вообще в первом приближении "действующий как коллекция" и "коллекция" это в принципе одно и то же. Потому что вообще само понятие "коллекция" - это уже абстракция. Правда абстракции частенько протекают, но это уже другая история.

Ну вообще в первом приближении "действующий как коллекция" и "коллекция" это в принципе одно и то же. Потому что вообще само понятие "коллекция" - это уже абстракция. Правда абстракции частенько протекают, но это уже другая история.

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

ну тоесть репозитории в программировании можно представить ввиде массива и мапы?

Нет. Массив и мапу можно представить в виде репозитория.

массив, мапу, указатель, юникс тайм - что угодно

массив, мапу, указатель, юникс тайм - что угодно

Именно

отлично. А можно вкачстве итога этой офигеть какой полезной дискуссии приветси пример, иллюстрирующей реальную пользу от использования репозитория в качестве абстракции базы? не связанный с переносом приложения от одной субд к другой, или там от БД к веб данным

ты сам понимаешь что несёшь?)

я в самом начале разговора сказал, что таких не видел. Переходы подобные - редкость. И?

покрытие юнит-тестами бизнес-логики с использованием реализации репозитория в оперативной памяти

ты сам понимаешь что несёшь?)

ну то есть по делу тебе сказать нечего

покрытие юнит-тестами бизнес-логики с использованием реализации репозитория в оперативной памяти

мокать базу??

ну то есть по делу тебе сказать нечего

да, просто ты явно не оч в курсе за тему, в которую полез. Жаль тот джун нарвался на такого, как ты :)

мокать базу??

не всю, а только необходимые репозитории

persistence ignorance, все дела. Но если чувак не понимает и не видет плюсов, а всяки фаулеры и бобы для него не авторитет, то чё толку с ним говорить

Вообще давайте начнём с того, что если бизнеслогика знает про существование базы - это уже не круто. Не, если пишете маленькую программку в команде из трёх человек, то вообще без разницы.

В чем практичный смысл Репозитория?

persistence ignorance, все дела. Но если чувак не понимает и не видет плюсов, а всяки фаулеры и бобы для него не авторитет, то чё толку с ним говорить

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

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

она бессмысленная только для ламеров

для повелителей горутин, если угодно.

а, ну да, ну да

В чем практичный смысл Репозитория?

вот у меня точно такой же вопрос, только про orm

вот у меня точно такой же вопрос, только про orm

Отделить доменный слой от хранилища.

не всю, а только необходимые репозитории

зачем? проще создать тестовую БД и спокойно тестить по ней

что бы понимать зачем это, надо понимать что есть доменный слой и что есть хранилище.

А тут рассказывать и не надо на самом деле. Нужно чтобы человек сам сначала окунулся в построение архитектуры более-менее крупного приложения. Тогда он сам будет изобретать те самые репозитории.

В чем практичный смысл Репозитория?

1. чтобы было 2. чтобы было как рассказали чуваки на конфах 3. чтобы было, как написано у дяди боба (как они это понимают) далее следует бред про БЛ слой и слой хранилища

зачем? проще создать тестовую БД и спокойно тестить по ней

Когда у вас очень много тестов и они часто крутятся, то в оперативке будет быстрее.

если ты пишешь бложики на горутинах, тебе всё это не нужно) и так сойдёт.

отдельную тестовую БД есть смысл на интеграционное тестирование, не на юнит

Когда у вас очень много тестов и они часто крутятся, то в оперативке будет быстрее.

да. для этого есть in-memry БД

правильно

о, мы тут в юнит тестах ещё тестируем базу данных. Прелесть какая

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

а как вы свою in-memory db подставите в код?

Я правильно понимаю что репозиторий мы строим по принципу структуры с методами аля Структура Post (db) Метод CreatePosts([]Post)?

Отделить доменный слой от хранилища.

ну опять же, я видел, где это делается на уровне repository. К примеру, есть метод FindByEmail(ctx, email), в котором написан SQL запрос под нужную БД, у репозитория есть свой объект, и при отдаче он конвертит в доменный объект

1. чтобы было 2. чтобы было как рассказали чуваки на конфах 3. чтобы было, как написано у дяди боба (как они это понимают) далее следует бред про БЛ слой и слой хранилища

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

Я правильно понимаю что репозиторий мы строим по принципу структуры с методами аля Структура Post (db) Метод CreatePosts([]Post)?

AddPost(post Post)

AddPost(post Post)

Ну тип того, да

Окей, в чем принципиально разница между вызовом метода структуры типа Post.Create()? В чем преимущества?

Ну тип того, да

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

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

Причём репозиторий - это далеко не единственный такой инструмент.

Окей, в чем принципиально разница между вызовом метода структуры типа Post.Create()? В чем преимущества?

и что оно делает?

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

ты действительно считаешь что до тебя я не слышал никогда этого бессмысленного набора слов? я каждую неделю на конфах

Окей, в чем принципиально разница между вызовом метода структуры типа Post.Create()? В чем преимущества?

самосоздаваемая сущность?)

самосоздаваемая сущность?)

актив рекордом пахнет)

и что оно делает?

Создаёт пост )

ты действительно считаешь что до тебя я не слышал никогда этого бессмысленного набора слов? я каждую неделю на конфах

ты зря тратишь время и зря пытаешься джунам рассказывать что они не правы. Нарвутся на вменяемых ребят, повторят за тобой и испортят карму.

самосоздаваемая сущность?)

Ну, получается так

Создаёт пост )

так пост уже создан - ты же из него метод вызываешь

ты действительно считаешь что до тебя я не слышал никогда этого бессмысленного набора слов? я каждую неделю на конфах

бессмысленный набор слов??? Я обычно стараюсь такого не говорить, ибо сам не без греха, но ты просто абсолютно некомпетентен как программист.

так пост уже создан - ты же из него метод вызываешь

Не, мы сначала инициализировали структуру с полями, потом вызвали метод на сохранение поста в Бд

а может это просто толстый тролль

Не, мы сначала инициализировали структуру с полями, потом вызвали метод на сохранение поста в Бд

вот инициализация - это и есть создание поста. а сохранение - это сохранение

ERROR: S client not available

а может это просто толстый тролль

Не бывает настолько толстых троллей (наверное).

вот инициализация - это и есть создание поста. а сохранение - это сохранение

Инициализировали в коде, Create - метод на создание поста в Бд

Инициализировали в коде, Create - метод на создание поста в Бд

и я про то же

Не бывает настолько толстых троллей (наверное).

https://ru.wikipedia.org/wiki/%D0%AD%D1%84%D1%84%D0%B5%D0%BA%D1%82_%D0%94%D0%B0%D0%BD%D0%BD%D0%B8%D0%BD%D0%B3%D0%B0_%E2%80%94_%D0%9A%D1%80%D1%8E%D0%B3%D0%B5%D1%80%D0%B0

и я про то же

Окей, тогда вы о чем?

Я спрашиваю про разницу между подходами

бессмысленный набор слов??? Я обычно стараюсь такого не говорить, ибо сам не без греха, но ты просто абсолютно некомпетентен как программист.

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

https://ru.wikipedia.org/wiki/%D0%AD%D1%84%D1%84%D0%B5%D0%BA%D1%82_%D0%94%D0%B0%D0%BD%D0%BD%D0%B8%D0%BD%D0%B3%D0%B0_%E2%80%94_%D0%9A%D1%80%D1%8E%D0%B3%D0%B5%D1%80%D0%B0

Pawel - прям эталон.

Я спрашиваю про разницу между подходами

Условно, если у вас будет несколько постов, то в вашем случае каждый инстанс поста будет иметь в себе соединение с БД верно?

Я спрашиваю про разницу между подходами

репозиторий - это абстрагирование от хранилища.

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

если вы не поняли, то в данном случае это говорит о вашей компетенции

если вы не поняли, то в данном случае это говорит о вашей компетенции

нет. Это говорит о том, что человек не понимает о чём он говорит и зачем

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

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

я его понимаю

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

Не кормите тролля)

поддерживаю

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

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

Скорее людей в принципе)

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

Это бессодержательно, потому что я пример просил, а ты решил отделаться общими словами

репозиторий - это абстрагирование от хранилища.

За счёт чего происходит абстракция? И почему в подходе который я предложил ее нет?

Это бессодержательно, потому что я пример просил, а ты решил отделаться общими словами

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

За счёт чего происходит абстракция? И почему в подходе который я предложил ее нет?

я не говорил, что ее нет. указал лишь на количество ответственностей сущности. сущность занимается не своим делом

Да тут и примеры уже не помогут

За счёт чего происходит абстракция? И почему в подходе который я предложил ее нет?

ты про свой пример active record'a c методом create?

у тебя сущность знает как себя создать, сохранить и изменить. если она себя ещё и получать сможет, хуже не станет. тут проблема в разделении ответственности. Вариант с использованием тех же репозиториев подразумевает иную степень изоляции

в active record сущность сама знает как себя положить в базу, а вообще не должна об этом знать, так как опять же создаёт ненужную жёсткую связь между базой и сущностью

За счёт чего происходит абстракция? И почему в подходе который я предложил ее нет?

В вашем подходе вы смешиваете данные и работу с этими данными. Репозиторий же предоставляет интерфейс для работы с данными. Вот условно у вас есть юзер. Юзеры могут быть в кэше и в бд. В случае с вашим подходом, нужно создавать две сущности userdb и usercache. И они будут содержать данные и работу с конкретной реализацией. А теперь выдергиваем данные юзера в отдельную структуру. Где будут только поля + два репозитория бд и кэш, которые имеют схожие интерфейсы и принимают/возвращают инстанс структуры юзера

таким образом вы отделяете логику работы с конкретной БД и данные

я уже писал ранее, повторю ещё раз: это всё часть persistence ignorance

В вашем подходе вы смешиваете данные и работу с этими данными. Репозиторий же предоставляет интерфейс для работы с данными. Вот условно у вас есть юзер. Юзеры могут быть в кэше и в бд. В случае с вашим подходом, нужно создавать две сущности userdb и usercache. И они будут содержать данные и работу с конкретной реализацией. А теперь выдергиваем данные юзера в отдельную структуру. Где будут только поля + два репозитория бд и кэш, которые имеют схожие интерфейсы и принимают/возвращают инстанс структуры юзера

А почему создавать две? Почему мы не можем определить всю эту логику внутри метода получения Юзера?

Либо же сделать два метода, например