Когда мы передаем первичный ключ в пользовательский интерфейс, не следует ли его рассматривать как смешение двух слоев и ПЛОХОЙ практики?

Question

Когда мы передаем идентификатор Db любого объекта в пользовательский интерфейс (скажем, PrimaryKey объекта в строке запроса url), разве мы не смешиваем два слоя (уровень Persistnet и уровень представления) в основном?

Идентификатор базы данных звучит как данные, относящиеся к постоянному слою, только для меня, но когда мы «должны» передать их в пользовательском интерфейсе, это не BAD практика, где я понятия не имею, что может бытьхотя лучше.

Это в исключительном случае?

Короче говоря, как многоуровневая архитектура решает эту проблему, передавая данные постоянного уровня в UI?

Answer 1

Это своего рода Leaky Abstraction, с которой приходится иметь дело всем.

Есть и другие примеры утечки персистентности в другие слои, например, проверка длины строки в доменном слое, потому что длина столбца базы данных установлена ​​на некоторое значение.Другим примером может быть предоставление EF IQueryable из DAL на доменный уровень, поскольку при этом потенциальная схема базы данных просачивается на доменный уровень.

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

Но если у кого-то есть серебряная пуля, я буду рад услышать о:)

Answer 2

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

Полагаю, вы действительно говорите о суррогатных ключах , а не об идентификаторах или "первичных ключах" в целом. Вопрос в том, зачем вам вообще нужно было создавать такой ключ? В принципе, суррогатные ключи - отвратительный способ абстрагировать свой уровень представления от уровня данных именно потому, что они создают дилемму, которую вы описываете. Тот факт, что люди используют их таким образом, обычно обусловлен: слабой поддержкой SQL ключей и общим отсутствием независимости данных; наследие плохой практики отрасли; неадекватные инструменты разработки.