The level of access to data as a web service. Is that a good idea?

Question

I have been researching for some time and actually created a prototype ASP.NET web service as DAL for several ASP.NET 2.0 websites. I just would like to ask for insight / advice from more experienced developers who have successfully rolled out DAL as a web service. What are the disadvantages / risks for deploying DAL as a web service? What is the best way to protect or confirm the use of this web service? WCF is out of the question, I will code in VS 2005.

Thanks.

Answer 1

I think the biggest drawback of this approach is the extra overhead of calling a web service. If you need frequent requests / updates for the DAL, this can become quite slow.

My opinion is that this approach is a kind of reassessment if you really do not need to physically separate the DAL for different consumers, and you need additional verification / processing in the DAL (which is wrong in any case).

Protection can be quite simple. You can use SSL along with IIS authentication for your public service interface.

So these are my $ 0.03

Answer 2

Look at this in terms of the evolution of Enterprise Software Development projects:

• Start with a very simple, well-organized, and possibly new, application with few maintenance issues (if you're lucky). Programmers may be recent graduates, but the system is young or clean enough to be very agile and respond quickly to change requests. Most database code is stored in stored procedures. No dba.
• The application is growing, and the application needs to work with several programmers at the same time. New grads open source control to help them share code among several programmers and move away from stored procedures in favor of n-tier or ORM design to simplify the version of the database code. This works well, as long as each individual application is sufficiently isolated. The database administrator can now begin to help configure queries.
• Ultimately, this turns into an interconnected application system that has grown organically, not in design. Change requests become difficult as changes in one area have little impact on others. To solve this problem from several applications working with one database, and to share a common and complex business logic, programmers turn to service-oriented architecture (web services). Old data and business layers are analyzed, combined and reorganized into a common set of web services. Most programmers no longer know how to connect to their database - only those who work with basic services are allowed to do this, and even they should leave some kind of actual sql for the database administrator. If unit testing is not already in use, it is now detected as part of the continuous integration system setup.
• The system continues to grow, but business is growing even faster. Everything works; the quality is good and the performance is low, but still acceptable. The problem is that the changes are too slow. The process levels between programmers and code prevent them from keeping up with the business in a cost-effective way. Someone discovers flexible methods.
• Return to step 1.

To become serious again, putting it in this context, we see that web services really encompass both the data layer and the business layer. The goal of a service tier is to share a common set of rules among multiple applications. Exiting the business layer from your service gives programmers the opportunity to write their own business code for each application and that is really counterproductive to use the services in the first place.

Answer 3

The only real problem I have ever encountered was to expose data through an ASMX-based web service, and came up with all the methods needed to efficiently collect data. It is sometimes difficult to maintain discipline regarding the level between the application and the database.

If you are deploying Intranet with AD, Integrated Windows Authentication is a great way to control who can and cannot interact with the service. It is useful to group service classes by customer role, so permissions can be declaratively managed in Web.config . I try to store read methods in a different service class than implement update and delete methods.

Avoid frequent service calls. Of course, it is good to avoid frequent database calls in a two-tier system, but you will pay the driver for frequent calls when you increase the number of levels. Choose to send large objects. For example, if you have a table with several search queries, sending an object through postings with previously viewed values ​​will often save you a second or third call and should not cause excessive system load.

I hope these ideas help.

Answer 4

I would recommend against this until you switch to WCF. Otherwise, you will transfer all your data back and forth in XML text format over HTTP, which will significantly slow down the work. You will also have very few security choices, limited to SSL for encryption.

WCF allows you to send binary data over TCP / IP, named pipes or message queues, and allows you more flexibility in terms of security.