Monday, August 18, 2008
Should We Really Be Exposing Our Data As A Service?
byADO.NET Data Services (better known by its Project code name “Astoria”) was released with SP1 for .NET. The idea behind ADO .NET is that it exposes data, represented as Entity Data Model (EDM) objects, via web services accessed over HTTP. But is exposing the data this way really a good idea? I tend to agree with Arnon Rotem-Gal-Oz, and think that this is a horrible design idea.
My major complaints with ADO.NET Data Services come from that fact that it allows developers to skip the service layer completely. Now I realize that supporters will point out that ADO.NET Data Services can be viewed as a replacement for the service layer, but I would disagree. There is no business logic at all in Astoria, so it isn’t really a service package. Any business rules would have to be forced into the data layer, or be exposed to the client layer. I would consider both options poor design.
Maybe a better name would have been ADO.NET Data Access Layer… However, even in as a DAO it falls short because as Arnon explains, it exposes ”internal database structure or data rather than a thought-out contract.”
I can understand where Microsoft was going with Astoria, but I think they missed the mark. The idea of bundling data into common and easy to use structures like JSON and XML is very appealing from the cleint side. However, we don’t need shortcuts that allow us direct data access from client apps. I would have rather seen some kind of library that allowed easy conversion of data into those data structures that we could use in our own service layers as need be. I will be curious to see where ADO.NET Data Services eventually fits in to the .NET development world.
