2

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?

pencilCake
  • 51,323
  • 85
  • 226
  • 363

2 Answers2

3

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 :)

Tomasz Jaskuλa
  • 15,723
  • 5
  • 46
  • 73
  • 2
    +1 Nice explanation. Id is such a natural thing. Whenever you want to identify an object particularly you need and identifier of some sort. Having different id for presentation is overkill. So exposing persistent id AS READ ONLY to presentation tier can hardly be a BAD practice. However, setting persistence id from the presentation tier IS BAD practice. – Shuhel Ahmed Jun 20 '11 at 12:17
  • Having said that, just because an item has a unique id doesn't mean that id has to come from a database or have been generated by the persistence layer. – Adrian K Jun 20 '11 at 13:25
1

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.

nvogel
  • 24,981
  • 1
  • 44
  • 82