В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Android Architecture

2645 membersпожаловаться на группу
2020 October 07

AV

Alex Vayts in Android Architecture
Konstantin Dovnar
Беда в том, что в этом кейсе выше — это тоже суть.

Это не абстрагирование уровня "сейчас мы сохраним в shared'ы, а как дойдут руки сделаем нормальную sqlite табличку", это бизнес-правило которое говорит тебе "мне нужно именно это".

Как выше спросил — проверку длины пароля тоже вынесите в data?
Валидацию входных данных? Я бы сделал в 2 местах:
* на сервере (ответит 401/403)
* поближе к UI в презентейшене. Сам валидатор можно сделать на domain-слое, но использовать его в presentation’е

в use-case авторизации добавлять бы не стал, если туда передадут плохие данные - защитит сервер
источник
18:43пожаловаться#1

KD

Konstantin Dovnar in Android Architecture
Alex Vayts
Валидацию входных данных? Я бы сделал в 2 местах:
* на сервере (ответит 401/403)
* поближе к UI в презентейшене. Сам валидатор можно сделать на domain-слое, но использовать его в presentation’е

в use-case авторизации добавлять бы не стал, если туда передадут плохие данные - защитит сервер
Хорошо, видимо надо было с этого начать.
Тогда у нас слишком разных взгляд на реализацию бизнес-логики:)
источник
18:44пожаловаться#2

AV

Alex Vayts in Android Architecture
Konstantin Dovnar
Хорошо, видимо надо было с этого начать.
Тогда у нас слишком разных взгляд на реализацию бизнес-логики:)
Я могу пояснить 🙂 как правило эта валидация привязана к каким-нибудь подсветкам поля пароля. Какой-нибудь password-power-meter красно-желто-зеленый.

Надо там на каждую букву реагировать и менять эти цвета и получается, что в презентейшене валидация данных всяко будет.

А передача по кнопке “submit” она будет одна, по клику и тогда уже use-case авторизации отработает
источник
18:46пожаловаться#3

YW

Yakov Weber in Android Architecture
Alex Vayts
Я могу пояснить 🙂 как правило эта валидация привязана к каким-нибудь подсветкам поля пароля. Какой-нибудь password-power-meter красно-желто-зеленый.

Надо там на каждую букву реагировать и менять эти цвета и получается, что в презентейшене валидация данных всяко будет.

А передача по кнопке “submit” она будет одна, по клику и тогда уже use-case авторизации отработает
Можно просто входящие данные отправлять в domein для валидации, возвращать же структуру с ответом на валидацию и индекс неверного символа, далее ui уже на основе этих данных подсветит символ, это решания будет более маштабируемым и кроссплатформеным.
источник
18:49пожаловаться#4

KD

Konstantin Dovnar in Android Architecture
Alex Vayts
Я могу пояснить 🙂 как правило эта валидация привязана к каким-нибудь подсветкам поля пароля. Какой-нибудь password-power-meter красно-желто-зеленый.

Надо там на каждую букву реагировать и менять эти цвета и получается, что в презентейшене валидация данных всяко будет.

А передача по кнопке “submit” она будет одна, по клику и тогда уже use-case авторизации отработает
>как правило
Не надо мыслить только стереотипами, выше уже говорил о том, что всё бывает очень разным.
От того, что "как правило" где-то что-то как-то делается — не значит, что везде надо делать так.

(но и в целом, к счастью, это далеко не стандарт и чаще делают именно по заполнению полей или нажатию кнопки. когда у тебя валидация идёт на каждый символ — это ужасно)
источник
18:50пожаловаться#5

KD

Konstantin Dovnar in Android Architecture
Yakov Weber
Можно просто входящие данные отправлять в domein для валидации, возвращать же структуру с ответом на валидацию и индекс неверного символа, далее ui уже на основе этих данных подсветит символ, это решания будет более маштабируемым и кроссплатформеным.
Опередил:)
источник
18:50пожаловаться#6

AV

Alex Vayts in Android Architecture
Yakov Weber
Можно просто входящие данные отправлять в domein для валидации, возвращать же структуру с ответом на валидацию и индекс неверного символа, далее ui уже на основе этих данных подсветит символ, это решания будет более маштабируемым и кроссплатформеным.
Я же это и описал 🙂 без деталей какую схему возвращает валидатор в ответ.

Что есть валидация на ввод нового символа, а есть вызов завершающий, на клик в кнопку

А на кнопку после валидатора можно отправить уже в use-case “сделай авторизацию вот тебе input”.  и там ответ будет не валидационный, а “успех/ошибка"
источник
18:53пожаловаться#7

YW

Yakov Weber in Android Architecture
Alex Vayts
Я же это и описал 🙂 без деталей какую схему возвращает валидатор в ответ.

Что есть валидация на ввод нового символа, а есть вызов завершающий, на клик в кнопку

А на кнопку после валидатора можно отправить уже в use-case “сделай авторизацию вот тебе input”.  и там ответ будет не валидационный, а “успех/ошибка"
Это можно сделать и на каждый символ, если это необходимо.
источник
18:54пожаловаться#8

KD

Konstantin Dovnar in Android Architecture
Alex Vayts
Я же это и описал 🙂 без деталей какую схему возвращает валидатор в ответ.

Что есть валидация на ввод нового символа, а есть вызов завершающий, на клик в кнопку

А на кнопку после валидатора можно отправить уже в use-case “сделай авторизацию вот тебе input”.  и там ответ будет не валидационный, а “успех/ошибка"
Ты описал это так, что это не бизнес-логика, а какая-то там проверка у UI. Это разные вещи.
источник
18:54пожаловаться#9

AV

Alex Vayts in Android Architecture
Yakov Weber
Это можно сделать и на каждый символ, если это необходимо.
Тогда у тебя на каждый символ уйдет запрос авторизации - это уже ошибка..
источник
18:54пожаловаться#10

YW

Yakov Weber in Android Architecture
Alex Vayts
Тогда у тебя на каждый символ уйдет запрос авторизации - это уже ошибка..
Запрос уйдёт при нажатии на кнопку, проверку валидации же можно сделать реактивной (на каждый новый  символ например) и тогда при нажатии можно уже сделать просто запрос на авторизацию.
источник
18:56пожаловаться#11

YW

Yakov Weber in Android Architecture
Alex Vayts
Тогда у тебя на каждый символ уйдет запрос авторизации - это уже ошибка..
И эта проверка будет все также в domein слое
источник
18:57пожаловаться#12

KD

Konstantin Dovnar in Android Architecture
Давайте определимся.
Кейс валидации каждого символа (фу) — это не тоже самое, что валидация данных перед отправкой.

Если у тебя в бизнес-правилах написано, что пароль должен быть меньше 6 символов, то валидация на это перед отправкой должна быть в UseCase.

@o_Ohmy, ты снова разбил одну вещь на несколько разных.
источник
18:57пожаловаться#13

AV

Alex Vayts in Android Architecture
Yakov Weber
Запрос уйдёт при нажатии на кнопку, проверку валидации же можно сделать реактивной (на каждый новый  символ например) и тогда при нажатии можно уже сделать просто запрос на авторизацию.
Верно, согласен. https://t.me/Android_Architecture/103617

Так и написал:)
Telegram
Alex Vayts in Android Architecture
Валидацию входных данных? Я бы сделал в 2 местах:
* на сервере (ответит 401/403)
* поближе к UI в презентейшене. Сам валидатор можно сделать на domain-слое, но использовать его в presentation’е

в use-case авторизации добавлять бы не стал, если туда передадут плохие данные - защитит сервер
источник
18:57пожаловаться#14

P

Pavel in Android Architecture
Ранее обещанная схемка
источник
19:56пожаловаться#15

P

Pavel in Android Architecture
Предлагаю провести опрос :)
источник
19:57пожаловаться#16

P

Pavel in Android Architecture
Как называть сущность 1 и сущность 2.
Варианты:

1 - data source, 2 - repository

1 - repository, 2 - interactor
источник
19:58пожаловаться#17

P

Pavel in Android Architecture
Странно, не могу сделать опрос. Может, только админы могут?
источник
19:59пожаловаться#18

NM

Nick Marchuk in Android Architecture
Сущность 1 - Repository
Сущность 2 - Interactor

Но я б переименовал InteractorImpl(тот что сверху) на UseCase
источник
20:02пожаловаться#19

I

Igor in Android Architecture
Как называть сущность 1 и сущность 2?
Анонимный опрос
34%
1 - data source, 2 - repository
66%
1 - repository, 2 - interactor
Проголосовало: 29
источник
20:02пожаловаться#20