When we pass a primary-key to UI, should not it be considered as mixing of 2 layers and a BAD practice?

When we pass a Db identifier of any object to the UI (Let's say the PrimaryKey of an object in the url query string) aren't we mixing two layers (Persistnet layer and presentation layer) basically?

A data-base identifier sounds like a persistent layer related data only to me in a way, but when we 'have' to pass it on UI, isn't is a kind of BAD practice, where I have no idea what could be a better one though.开发者_开发技巧

Is it in an exceptional case?

In short, how does the multi-tier architecture addresses this practice, passing a persistent layer data to UI?

It's a kind of a Leaky Abstraction everybody has to deal with.

There is more examples of persistance leaking to other layers as for example validating string lenght in domain layer because the lenght in the database column is set to some value. Another example could be exposing EF IQueryable from DAL to domain layer, because doing that the potenital database scheme is leaking to the domain layer.

So I think there is a acceptable compromise we could deal with and we can't eliminate leaky abstraction at all but we should work hard to have it at minimum. Exposing the ID to UI is a such acceptable compromise I deal with because it's simple and everybody understand it.

But if someone has a silver bullet I will be glad to hear about :)

The application user needs identifiers so she can correctly identify and interact with the data in the database. There's nothing bad about exposing the same identifiers in all layers of your solution. It would be hard to get anything useful done without them.

I expect you are really talking about surrogate keys rather than identifiers or "primary keys" in general. The question is, why did you need to create such a key in the first place? In principle, surrogate keys are lousy way to abstract your presentation tier from the data tier precisely because they create the sort of dilemma you are describing. The fact that people use them that way is usually due to: SQL's poor support for keys and general lack of data independence; a legacy of industry bad practices; inadequate development tools.