title: Exposing Database IDs to the UI
body: <p>This is a beginner pattern question for a web forms-over-data sort of thing. I read <a href="https://stackoverflow.com/questions/396164/exposing-database-ids-security-risk">Exposing database IDs - security risk?</a> and the accepted answer has me thinking that this is a waste of time, but wait...</p>
  
  <p>I have an MVC project referencing a business logic library, and an assembly of NHibernate SQL repositories referencing the same. If something forced my hand to go and reference those repositories directly from my controller codebase, I'd know what went wrong. But when those controllers talk in URL parameters with the database record IDs, does it only <em>seem</em> wrong?</p>
  
  <p>I can't conceive of those IDs ever turning un-consumable (by MVC actions). I don't <em>think</em> I'd ever need two UI entities corresponding to the same row in the database. I don't intend for the controller to interpret the ID in any way. Surrogate keys would make zero difference. Still, I want to have the problem because assumptions about the ralational design aren't any better than layer-skipping dependencies.</p>
  
  <p><em>How would you make a web application that only references the business logic assembly and talks in BL objects and GUIDs that only have meaning for that session, while the assembly persists transactions using database IDs?</em></p>