Data Access Layer as a web service -- Is this a good idea?

Question

I have been researching for a while and have actually created a prototype ASP.NET web service as a DAL for a few ASP.NET 2.0 web sites. Just would like to ask for some insight/advice from more experienced developers out there who had successfully rolled out DAL as a web service. What are the drawbacks/risks to deploying DAL as a web service? What is the best way to secure or authenticate consumption of this web service? WCF is out of the question, I'll be coding in VS 2005.

Thank you.

Answer 1

I think, that biggest drawback of such approach is additional overhead of calling web service. If you need frequent queries/updates to DAL, this can get quite slow.

My opinion is, that such approach is kind of overengineering, unless you really need to have physically separate DAL for different consumers and you need some additional validation/processing in DAL (which is kind of wrong anyway).

Securing can be quite a simple. You can use SSL together with IIS authentication for your public service interface.

So, those are my $0.03

Answer 2

The only real challenge I ever faced with exposing data over an ASMX-based web service was dreaming up all the methods required to get data efficiently. Sometimes it's hard to have the discipline to honor the tier between the application and the database.

If you are deploying to an Intranet environment with AD, Integrated Windows Authentication is an excellent way to control who can and cannot interact with a service. It is helpful to group service classes by the consumer roles, so that permissions can be controlled declaratively in the Web.config. I tend to keep read methods in a different service class than insert update and delete methods

Avoid chatty service calls. Of course, it is well to avoid chatty database calls in a 2-tier system, but you'll pay the piper for chatty calls when you increase the number of tiers. Choose to send larger objects. For example, if you have a table with a few lookups, sending an object across the wire with pre-looked-up values will often save you a second or third call, and shouldn't cause undue burden on the system.

I hope these ideas help.

Answer 3

I would recommend against this until you can move to WCF. Otherwise, you'll be passing all your data back and forth in text-based XML over HTTP, which will slow things down substantially. You'll also have very little choice about security, being limited to SSL for encryption.

WCF will allow you to send binary data over TCP/IP, named pipes or message queues, and will allow you a great deal of flexibility in terms of security.

Answer 4

Let's look at this from the standpoint of the Evolution of "Enterprise" Software Development projects:

1. Begin with a very simple, well-organized, and perhaps new application with little maintenance issues (if you're lucky). Programmers might be recent grads, but the system is young enough that they can be very agile and quickly respond to change requests. Most database code is in stored procedures. There is no DBA involved.
2. The application grows and there is a need for multiple programmers to work in the app at the same time. The new grads discover source control to help them share code among multiple programmers and move away from stored procedures in favor of n-Tier design or an ORM to make it easier to version the database code. This works well as long as each individual app is fairly isolated. A DBA may now begin helping to tune queries.
3. This eventually evolves into an interconnected system of apps that has grown organically rather than by design. Change requests become difficult, as changes in one area have subtle effects in others. To solve this problem of multiple apps talking to the same database and needing to share common and complex business logic, the programmers turn to a service oriented architecture (web services). Old data and business tiers are analyzed, combined, and refactored into a common set of web services. Most programmers now no longer even know how to connect to their database - only those working on the core services are allowed to do this, and even they must leave any actual sql to the DBA. If unit testing is not already in use it is now discovered as part of setting up a continuous integration system.
4. The system continues to grow, but the business grows even faster. Every things works; quality is good and performance is not great, but still acceptable. The problem is that change rates are too slow. The layers of process between the programmers and code prevent them from keeping up with the business in a cost effective way. Someone discovers agile methods. Go to step one.

To get serious again, putting it in this context we see that web services really encompass both the data layer and the business layer. The purpose of a service layer is to enforce sharing a common set of rules among several applications. Leaving the business layer out of your service gives programmers the chance to write their own business code for each application, and that's really counter-productive to the purpose of using services in the first place.