There's an interesting, if not controversial, article over on TheServerSide.NET about how the data access layer should be treated. Rocky Lhotka says it should be treated like an external interface because in most applications, you never have complete control over the database.

I guess that depends on the application. If you are building a stand alone application (such as the Tourney Pool Manager), then you can almost count on it being a part of the application. On the other hand, if you are working against an existing database to add a new way to access the data, then I can see his argument.

I'm not sure I would go as far as calling it an external interface, but I do agree that if you are working with a shared data store (remember, not everyone uses a database to store data), you need to keep that in mind when you build your data layer. Not all data can be assumed to be in the format you expect it, and you have to be prepared to handle that situation.

We recently ran into that situation when we started talking about caching. Because the data store was shared and we cached data tables, we needed a way to ensure that if the table was updated outside of our application, the application could be notified so the cache could be dumped.

We had to treat the data store as an "external interface" because we couldn't guarantee that our data would be in the same state we left it in. I put external interface in quotes because it's not truly an external interface. We just need to be careful when we read data from it. We need to verify it is what we expected, and handle the case when it isn't.

And that's what the article really is saying. Treat the database the same as you treat user input - with caution! Don't trust what it is telling you. Verify and validate it.

And before you say, "My data store is for me only!" remember this: Just because your application created the data store and expects to be the sole accessor of that data, doesn't mean that's the case. For example, the Tourney Pool Manager can use a SQL Server database and it expects it will be the only one accessing the database, but that doesn't mean that's the case. Anyone can get access to a SQL database. We had a client request a full data export, so we wrote another application that worked with the database. Now, all of a sudden, there are two applications using the same data store, and at least one expects to be the sole user.