Н
storage.Storage - выглядит странно, вот notes.Storage который лежит внутри пакета notes, который используется там же, а реализуется пакетом redis (к примеру) я бы еще понялSize: a a a
2020 June 06
AK
Н
storage.Storage - выглядит странно, вот notes.Storage который лежит внутри пакета notes, который используется там же, а реализуется пакетом redis (к примеру) я бы еще понялМетоды для работы с конкретной сущностью в БД ведь используются не только в одноименных юзкейсах. На примере уведомлений – они могут создаваться с юзкейсов создания поста, либо добавление друга. Либо комментарии. Их список может потребоваться в методе вывода поста.
VL
Методы для работы с конкретной сущностью в БД ведь используются не только в одноименных юзкейсах. На примере уведомлений – они могут создаваться с юзкейсов создания поста, либо добавление друга. Либо комментарии. Их список может потребоваться в методе вывода поста.
Один убер класс всегда сложнее и менее поворотлив, чем несколько небольших.
AK
Методы для работы с конкретной сущностью в БД ведь используются не только в одноименных юзкейсах. На примере уведомлений – они могут создаваться с юзкейсов создания поста, либо добавление друга. Либо комментарии. Их список может потребоваться в методе вывода поста.
Если говорить о Clean, интерфейсы как в примере выше проектируются (под бизнес юзкейс) и лежат в слое высокого уровня, и используются там же. А их реализации находятся в слое нижнего уровня (В пакете с БД). И именно пакет БД должен реализовывать бизнесовые интерфейсы а не наоборот.
Н
Если говорить о Clean, интерфейсы как в примере выше проектируются (под бизнес юзкейс) и лежат в слое высокого уровня, и используются там же. А их реализации находятся в слое нижнего уровня (В пакете с БД). И именно пакет БД должен реализовывать бизнесовые интерфейсы а не наоборот.
Что вы имеете ввиду под бизнесовыми интерефейсами?
VL
Смотрите, я не пытаюсь тут реализовать то, о чем говорит Мартин. Я пытаюсь понять, что плохого в архитектуре той, которая сейчас есть на примерном проекте. Какие конкретно минусы
Плохо то, что контроллер зависит от реализации хранилища, а не сам определяет через интерфейс какое хранилище ему нужно.
AK
Смотрите, я не пытаюсь тут реализовать то, о чем говорит Мартин. Я пытаюсь понять, что плохого в архитектуре той, которая сейчас есть на примерном проекте. Какие конкретно минусы
Минусы такие же как в любом классическом MVC Web фреймворке. Самый очевидный, искажение концепции MVC пришедшей из SmallTalk и UI разработки. Со всеми вытекающими отсюда последствиями. Берем любой проект написаный на MVC веб фреймворке с 5 летней историей и выше и смотрим, что с ним случилось и как с этим жить. Там прямо с каждого файла они огромными глазищами на вас смотрят при любой попытке внести изменение