MG
Ну, это может не самый удачный пример, но да - это часть домена. Если выносить это куда-то выше на уровень контроллеров там где проверяется существование - это размазывание логики
Size: a a a
2021 January 19
AC
@MrOnlineCoder вам нужно описать интерфейс репозитория и в своих сервисах использывать только интерфейс, а то какая реализация у интерфейса сервису не важно.
N
@MrOnlineCoder вам нужно описать интерфейс репозитория и в своих сервисах использывать только интерфейс, а то какая реализация у интерфейса сервису не важно.
спасибо, это в будущем позволяет заменить реализацию или замокать ее в тестах без изменения кода сервиса?
AC
спасибо, это в будущем позволяет заменить реализацию или замокать ее в тестах без изменения кода сервиса?
Верно
SF
спасибо, это в будущем позволяет заменить реализацию или замокать ее в тестах без изменения кода сервиса?
Не замокать, а подставить фейковую реализацию
N
Не замокать, а подставить фейковую реализацию
+
AC
Не замокать, а подставить фейковую реализацию
Ну замокать контракт легче, так что это тоже верно
N
@MrOnlineCoder вам нужно описать интерфейс репозитория и в своих сервисах использывать только интерфейс, а то какая реализация у интерфейса сервису не важно.
а такой подход свойственный всем архитектурам или есть альтерантивные варианты? есть ли архитектуры без DI?
т.е. читая книгу про DDD, Onion или любую другую - использование такого подхода само собой разумеется?
т.е. читая книгу про DDD, Onion или любую другую - использование такого подхода само собой разумеется?
SF
Ну замокать контракт легче, так что это тоже верно
Не уверен, что легче, но правильнее, на мой взгляд, сделать фейк
AC
а такой подход свойственный всем архитектурам или есть альтерантивные варианты? есть ли архитектуры без DI?
т.е. читая книгу про DDD, Onion или любую другую - использование такого подхода само собой разумеется?
т.е. читая книгу про DDD, Onion или любую другую - использование такого подхода само собой разумеется?
ddd тут не причем, старайтесь не уходить в такие вещи, пока плаваете в более простых вещях. Di не обязательно, но тут зависит от языка, например в пых было бы странно не использывать di, при этом в каком нибудь го это нормально
N
ddd тут не причем, старайтесь не уходить в такие вещи, пока плаваете в более простых вещях. Di не обязательно, но тут зависит от языка, например в пых было бы странно не использывать di, при этом в каком нибудь го это нормально
что тогда использовать если еще на розбарался в основе а код написать нужно?)
IS
Ну как-то же писали код до того, как выдумали SOLID, DDD, GRASP и прочее.
Необязательно проектировать небоскрёб, если нужно построить шалаш.
Необязательно проектировать небоскрёб, если нужно построить шалаш.
ST
что тогда использовать если еще на розбарался в основе а код написать нужно?)
DDD = SOLID + Ubiquitos Language)
ЕР
@MrOnlineCoder вам нужно описать интерфейс репозитория и в своих сервисах использывать только интерфейс, а то какая реализация у интерфейса сервису не важно.
Много у вас реализаций репозиториев?
N
Много у вас реализаций репозиториев?
если вопрос мне, то обычно конечно же одна)
ну и фейк для теста
ну и фейк для теста
ЕР
DDD = SOLID + Ubiquitos Language)
Ужас
ЕР
если вопрос мне, то обычно конечно же одна)
ну и фейк для теста
ну и фейк для теста
Ну вот и не нужен там интерфейс
AC
что тогда использовать если еще на розбарался в основе а код написать нужно?)
Перед написанием кода, я бы почитал, например
Patterns of Enterprise Application Architecture
fowler refactoring
Patterns of Enterprise Application Architecture
fowler refactoring
ЕР
что тогда использовать если еще на розбарался в основе а код написать нужно?)
Пихать запросы в репозиторий и не париться пока что
AC
Много у вас реализаций репозиториев?
Много это абстрактно.
Для вас много это сколько ?
Для вас много это сколько ?