B
Dmitry Russ (Aleksandrov)
Не понимаю, что там "реально облом"
Если все работает то облома нету)
Size: a a a
2021 March 05
DR
Помимо clickhouse-а, который завязан на Intel-овский процессор и не билдит image-и под арм - всё работало.
AD
Всем привет, вопрос по неймингу.
Есть базовая функция создания объекта, а есть функция создания объекта с бизнес логикой, которая использует первую. Например:
Вопрос - где вы храните обе функции, в одном контексте или как-то дополнительно разделяете? и как называете обе функции?
Есть базовая функция создания объекта, а есть функция создания объекта с бизнес логикой, которая использует первую. Например:
def create_message1(...) do
%Message{}
|> Message.changeset()
|> Repo.insert()
end
def create_message2(...) do
with {:ok, message} <- create_message1(...),
{:ok, _} <- create_log(...) do
{:ok, message}
end
end
Вопрос - где вы храните обе функции, в одном контексте или как-то дополнительно разделяете? и как называете обе функции?
ŹR
Есть контекст а есть сервис
AD
Есть контекст а есть сервис
а можешь привести пример как выглядит сервис и где находится? может статья какая-нибудь хорошая есть?
LL
Всем привет, вопрос по неймингу.
Есть базовая функция создания объекта, а есть функция создания объекта с бизнес логикой, которая использует первую. Например:
Вопрос - где вы храните обе функции, в одном контексте или как-то дополнительно разделяете? и как называете обе функции?
Есть базовая функция создания объекта, а есть функция создания объекта с бизнес логикой, которая использует первую. Например:
def create_message1(...) do
%Message{}
|> Message.changeset()
|> Repo.insert()
end
def create_message2(...) do
with {:ok, message} <- create_message1(...),
{:ok, _} <- create_log(...) do
{:ok, message}
end
end
Вопрос - где вы храните обе функции, в одном контексте или как-то дополнительно разделяете? и как называете обе функции?
А зачем две функции?
Может вам стоит разделить понятия
Первую функцию должен предоставлять контекст или сервис
Вторую функцию предоставляет модуль-сущность, хотя я больше люблю чтобы модуль сущность предоставлял
Может вам стоит разделить понятия
операции создания сущности (типа там создать пользователя с уникальными именем, записать это в лог, прислать ему письмо об этом и т.д.) и понятие создания сущности (просто записать в базу)Первую функцию должен предоставлять контекст или сервис
Вторую функцию предоставляет модуль-сущность, хотя я больше люблю чтобы модуль сущность предоставлял
changeset-ы и multiAD
так я их разделяю, вопрос как сделать это в коде
AD
А зачем две функции?
Может вам стоит разделить понятия
Первую функцию должен предоставлять контекст или сервис
Вторую функцию предоставляет модуль-сущность, хотя я больше люблю чтобы модуль сущность предоставлял
Может вам стоит разделить понятия
операции создания сущности (типа там создать пользователя с уникальными именем, записать это в лог, прислать ему письмо об этом и т.д.) и понятие создания сущности (просто записать в базу)Первую функцию должен предоставлять контекст или сервис
Вторую функцию предоставляет модуль-сущность, хотя я больше люблю чтобы модуль сущность предоставлял
changeset-ы и multiну т.е. записать create_message1 не в контекст, а в модуль-сущность?
LL
так я их разделяю, вопрос как сделать это в коде
Ну в коде это точно должно быть в разных модулях, типа это разные слои архитектуры (если у вас чистая архитектура)
AD
ну я и пытаюсь разделить по разным слоям, просто в гайдах того же феникса и тд ничего похожего нет
AD
создавать отдельный модуль для каждой операции мне кажется излишним
AD
тогда нужна какая-то структура этих модулей-сервисов
AD
создавать отдельный модуль для каждой операции мне кажется излишним
я пыталась откатиться от этого варианта и делать как пишут в phoenix все в контекстах, но тоже кажется не очень
LL
Не, ну я всегда на такой пример ориентируюсь
Есть модуль-сущность
Есть модуль-контекст
И этот
Есть модуль-сущность
User из которого торчат create_changeset, list_all_query и всё такоеЕсть модуль-контекст
Registration (или Auth), который типа "владеет" User-ом и делает register_user(attrs) :: {:ok, User.t()} | {:error, reason()} и всё такоеИ этот
register_user выполняет проверку на уникальность, регистрацию, логгирование и всё такоеAN
я пыталась откатиться от этого варианта и делать как пишут в phoenix все в контекстах, но тоже кажется не очень
Обычно разделяют чистые и грязные функции на разные модули, Changeset с проверками это чистые функции, вызов Repo это всегда грязная операция
AN
Так код и тесты понятнее
Н
Грязные в каком плане?
AN
Грязные в каком плане?
разный результат с оддинаковыми входными параметрами
LL
Грязные в каком плане?
Есть сайд-эффекты
Н
Понятно, спасибо.