RC
идея с провайдером выглядит вроде хорошо
Ну то есть факт того, что реализация провайдера знает про интерфейс репозитория - это норм? Потому что что-то внутри говорит мне "не", но объективных причин я не вижу :)
Size: a a a
2020 October 07
NM
Ну то есть факт того, что реализация провайдера знает про интерфейс репозитория - это норм? Потому что что-то внутри говорит мне "не", но объективных причин я не вижу :)
Если провайдер и репозиторий находятся в одном слое, то почему бы и нет
RC
Если провайдер и репозиторий находятся в одном слое, то почему бы и нет
Речь при этом идет про реализации или про интерфейсы? Или оба два?
E
Даггер же тоже на провайдерах работает, если я правильно помню, и ты как бы щас сделал провайдер, это как будто заинжектил Single<Stuff>
RC
Даггер же тоже на провайдерах работает, если я правильно помню, и ты как бы щас сделал провайдер, это как будто заинжектил Single<Stuff>
Даа, вот тоже об этом думал немного
В любом случае, спасибо всем откликнувшимся
В любом случае, спасибо всем откликнувшимся
E
твой провайдер просто обертка над репой и посуди тоже дата слой, вот)
KD
hash и соль не похоже на бизнес логику) это задача репозиторного уровня
а вот выбрать какому юзеру как именно собирать данные, на основе его прав доступа - это уже для домена
а вот выбрать какому юзеру как именно собирать данные, на основе его прав доступа - это уже для домена
Странное утверждение.
Бизнес логика есть бизнес логика.
Если тебе в ТЗ\таске\доке пишут, что авторизация выполняется посредством
Бизнес логика есть бизнес логика.
Если тебе в ТЗ\таске\доке пишут, что авторизация выполняется посредством
SHA256(username + password + salt), то это и есть бизнес-логика. Выносить это в репозиторий в данном случае некорректно.AV
Странное утверждение.
Бизнес логика есть бизнес логика.
Если тебе в ТЗ\таске\доке пишут, что авторизация выполняется посредством
Бизнес логика есть бизнес логика.
Если тебе в ТЗ\таске\доке пишут, что авторизация выполняется посредством
SHA256(username + password + salt), то это и есть бизнес-логика. Выносить это в репозиторий в данном случае некорректно.И если требуют шифровать данные в базе данных пишут в ТЗ - то тоже в домен выносить?
VP
Странное утверждение.
Бизнес логика есть бизнес логика.
Если тебе в ТЗ\таске\доке пишут, что авторизация выполняется посредством
Бизнес логика есть бизнес логика.
Если тебе в ТЗ\таске\доке пишут, что авторизация выполняется посредством
SHA256(username + password + salt), то это и есть бизнес-логика. Выносить это в репозиторий в данном случае некорректно.+
VP
И если требуют шифровать данные в базе данных пишут в ТЗ - то тоже в домен выносить?
Выносить в интерактор
KD
И если требуют шифровать данные в базе данных пишут в ТЗ - то тоже в домен выносить?
Хранение данных не относится к бизнес логике.
AV
Хранение данных не относится к бизнес логике.
Как и формат передачи данных для авторизации. Это же интеграционный вопрос системы.
D
Странное утверждение.
Бизнес логика есть бизнес логика.
Если тебе в ТЗ\таске\доке пишут, что авторизация выполняется посредством
Бизнес логика есть бизнес логика.
Если тебе в ТЗ\таске\доке пишут, что авторизация выполняется посредством
SHA256(username + password + salt), то это и есть бизнес-логика. Выносить это в репозиторий в данном случае некорректно.такая себе бизнес логика
D
бизнес логика = авторизация, sha256 - детали
AV
бизнес логика = авторизация, sha256 - детали
+
KD
Как и формат передачи данных для авторизации. Это же интеграционный вопрос системы.
Обработка данных — бизнес-логика.
В кейсе выше вполне себе могла быть бизнес логика (читай интерактор\юзкейс) который шифровал бы данные и отдавал дальше на хранение в
Так и хэширование данных для дальнейшей передачи на сервер.
В кейсе выше вполне себе могла быть бизнес логика (читай интерактор\юзкейс) который шифровал бы данные и отдавал дальше на хранение в
data.Так и хэширование данных для дальнейшей передачи на сервер.
KD
бизнес логика = авторизация, sha256 - детали
И если детали описаны в ТЗ — то они становятся частью бизнес-логики.
D
так в ТЗ и анимации могут быть описаны
AV
Обработка данных — бизнес-логика.
В кейсе выше вполне себе могла быть бизнес логика (читай интерактор\юзкейс) который шифровал бы данные и отдавал дальше на хранение в
Так и хэширование данных для дальнейшей передачи на сервер.
В кейсе выше вполне себе могла быть бизнес логика (читай интерактор\юзкейс) который шифровал бы данные и отдавал дальше на хранение в
data.Так и хэширование данных для дальнейшей передачи на сервер.
Боюсь у нас разный взгляд на эти вещи. Мое мнение, что не вся логика - бизнес-логика. Может быть логика в слое данных, связанная с детали транспортного слоя системы. Может быть логика отображения в презентере и она не бизнес тоже.
Вопрос как определить где какая - довольно творческий
Вопрос как определить где какая - довольно творческий
KD
так в ТЗ и анимации могут быть описаны
Не надо всё смешивать в кучу.
Есть описание авторизации. Если сервер должен себе получить уже хэшированные данные, то это вполне себе идёт в бизнес-логику. Туда же идёт проверка корректности данных и вот это вот всё.
Деталями реализации это было бы, если бы в ТЗ было указано "захэшируйте как попало и пришлите нам", а не "мы ждём SHA256(username + password)`.
Есть описание авторизации. Если сервер должен себе получить уже хэшированные данные, то это вполне себе идёт в бизнес-логику. Туда же идёт проверка корректности данных и вот это вот всё.
Деталями реализации это было бы, если бы в ТЗ было указано "захэшируйте как попало и пришлите нам", а не "мы ждём SHA256(username + password)`.