My Database is a Web Service

In The Fallacy of the Data Layer, Rocky Lhotka makes a case for something I've come to believe as absolute truth:

This is a companion discussion topic for the original blog entry at:

Nicely put. I think the line between “tier” and “service” is collapsing in favor of services. I don’t know if the “web” service (i.e. XML/HTTP/SOAP) is of primary importance, but I do agree that it’s not something that should be outrightly rejected by architects.

Well, there are a number of ways to deal with that:

  1. Don’t return so many rows in the first place(chatty vs. chunky). LDAP, for example, has a “governor” where it refuses to return more than (x) results and basically forces the developer to Page the results rather than grabbing a zillion directory entries.

  2. Explore HTTP compression. This works fine with web services, if the client is smart enough to enable it.

  3. Use a custom, tighter datatype or alternate method, eg, .GetRowsCompressed()

Lots of options.

I don’t understand. I found binary remoting to be pretty much as easy as WS.

I personally would use WS when you want to talk to more than one platform… or when your data requirements are [and will be in the forseeable future] pretty tame. (Although you might reconsider using .NET for the service tier in this case… because MS.NET has a wonderful way of not working well with other SOAP toolkits (what’s the point of SOAP again?))

There’s just no getting around the fact that XML is a bloated exchange language… and is just not feasible for a lot of applications. There’s just no need for all that translative markup if you’re talking to yourself[same platform].

That said… neither of our two favorite applications, IMO, warranted the need for remoting. WS would have worked just fine in those.

Good post, but I must disagree with the statement “web service data API is the right architecture…”. Statements like these are what get people in trouble in the first place – there are no silver bullets in software development.

Web services, remoting, COM+, stored procedures and so on are fantastic solutions to certain problems and yet absolutely awful solutions to others. I think it’s safe to say that most people developing software these days don’t do a ton of research. They read things here and there, get some training and do their job. When they’re told something is the way to go, they generally believe it and act on it. They’re given a hammer and everything looks like a nail.

Web service data access is nice concept and a wonderful solution to some problems, but certainly not all. It’s a great tool to add to the toolbox, but not quite good enough warrant emptying it. :slight_smile:

It’s a great tool to add to the toolbox, but not quite good enough warrant emptying it. :slight_smile:

In the absence of specifics, it’s always safer to err on the side of simplicity. And Web Services are both simple and flexible.

So what I’m saying is, you need a VERY good reason not to go this route. You could do a heck of a lot more damage by defaulting to something else.

I like the idea a lot. However, I’m still cringing at the idea of bringing down thousands of rows formatted as xml. This is going to add a lot more than 20ms. I still haven’t found a good solution to this issue…

One clarification: the situation I’m describing is only for apps that define a formal API.

For straightforward “app talking to database” apps, with no chance anyone else other than that single app is going to need to get to that data, I wouldn’t do this.

I believe that any DataLayer must be a simple code block, that they allow operations against DB.

That code block would not have to know on the Business Entities. Single to specialize it is to execute the operations (Store Procedures and SQL Sentences) against the engine DB (SQL, Oracle, DB2, etc.), with which this setting.

Finally, I invite to you to download the DataLayer.Primitives Public Version.

This is very cool Data Layer :slight_smile:

DataLayer.Primitives - Readme!
a href=""


Javier Luna
a href=""

Exactly what advantages does WS offer over a Data Access Layer developed through a simple Class Library ??

I was about to mention this book “Expert C# Business Objects” that I have been reading that presents an architecture that has a good implementation of what is being discussed, then I looked for a link to the book and realized Rocky (author of the article) wrote the book. So I guess I’ll just recommend the book!