D
а зачем тебе в жсон это совать?
пока не дошел до баз, и просто реализовал файловый репозиторий
а джсон для сериализации
а джсон для сериализации
Size: a a a
2020 October 22
D
но с удовольствием послушаю идеи другие для сериализации обьекта в го
А
ты не в том направлении копаешь, забудь про инкапсуляцию на ближайший месяц, оно само собой через небольшое время придет когда с пакетами нормально поработаешь
А
потом к ней вернешься но уже с другими взглядами
D
ты не в том направлении копаешь, забудь про инкапсуляцию на ближайший месяц, оно само собой через небольшое время придет когда с пакетами нормально поработаешь
ну вот я в качестве опытного "проекта" хочу реализовать круд для юзеров через базу + кеш
не хотелось бы сразу писать сущность открытую, это приведет к проблемам в будущем
не хотелось бы сразу писать сущность открытую, это приведет к проблемам в будущем
D
поэтому сразу и ищу варианты инкапсуляции данных, закрыв их от прямого изменения
в целом я могу открыть поля, не проблема, но хочу сразу понимать как мне их потом закрывать, предпочтительный способ или общепринятый
в целом я могу открыть поля, не проблема, но хочу сразу понимать как мне их потом закрывать, предпочтительный способ или общепринятый
А
не приведет если смотреть на это как на структуру а не как на класс, это просто данные которые ты берешь из одного места и кладешь в другое
D
не приведет если смотреть на это как на структуру а не как на класс, это просто данные которые ты берешь из одного места и кладешь в другое
хорошо, а как в таком случае реализуется сущность в терминах ддд в го ?
А
есть данные - структура, есть репозиторий который эти данные получает, есть юскейсы которые эти данные изменяет/аггрегирует и есть какой нибудь деливери который эти данные отдает/принимает извне
А
структура это просто данные которые берешь из одного места и отдаешь в другое
А
и да, их нужно менять иногда
x
мне кажется ты слишком зацикливаешься на инкапсуляции
+
D
согласен с вами, такой подход имеет место быть
грубо говоря
controller - handler -> get struct from repo-> change struct data -> save struct in repo?
грубо говоря
controller - handler -> get struct from repo-> change struct data -> save struct in repo?
А
пока что предстваь структуры как хеш, не закрывай
D
ага, и это общепринятый подход в го? я правильно понял ?
А
в большинстве случаев данные открыты, закрывают при необхоимости
D
т.е по сути вся бизнес логика у нас находится в хендлерах ?
D
а всякие ассерты на данные можно провести через методы самой структуры вроде User.ChangeEmail(value){
assert.isEmail(value)
user.email = value
}
примерно так ?
assert.isEmail(value)
user.email = value
}
примерно так ?
А
т.е по сути вся бизнес логика у нас находится в хендлерах ?
в ддд обычно 3 слоя:
слой который работает с данными извне
бизнесс логика
работа с хранилищем
слой который работает с данными извне
бизнесс логика
работа с хранилищем