views:

1899

answers:

5

Can anyone tell me what the need/advantage is to using a web service with an asp.net gui and using Linq to SQL? The web service layer seems unnecessary. Linq to SQL is completely new to me and I am researching as I am setting up a new project. Does anyone have any experience with this?

+2  A: 

It is certainly not necessary, but can be handy in case you want to keep your data access layer on a separate server from your presentation server (ASP.NET). A web service allows you to restrict communication between the two servers to only port 80.

Note that this could apply to plain old ADO.NET or anything else too.

swilliams
A web service can be deployed to any port, not just 80.
DOK
I think he means restrict to a single port, such as 80, for firewall security in between.
cfeduke
@cfeduke - bingo.
swilliams
+5  A: 

You would expose services for those cases in which other applications may need to access your data (such as a smart client, another application, a winforms app, etc.). A lot of people will develop using web services to prevent themselves from having to restructure to web services in the future.

In almost any professional/enterprise web application you want to separate the UI tier from the data access layer so you would not embed Linq to SQL calls in the UI tier. Instead you would have a service tier in between, whether its web services, WCF, or just a DLL with business logic that orchestrates your data access layer. Independent tiers are easier to maintain, update, refactor, and learn so the up front investment in creating them is worth the effort.

cfeduke
thanks cfeduke! again, i'm new so...we have an asp.net project and a web service project in our solution - are you suggesting to create a 3rd project for the linq OR put the linq in the web service?
I'm pretty sure cfeduke is saying that the linq queries would go safely in the web service. This is actually a pretty standard model even for non-webservice implementations.
MojoFilter
k thanks! that's what i thought just wanted to confirm!
Whether or not to use a web service may depend upon the scale of your application. We had a spirited discussion here about not using a web service for a DAL if your app isn't going to be deployed to a web farm.http://stackoverflow.com/questions/204653/when-should-a-web-service-not-be-used
DOK
Yeah keep in mind a web service layer will complicate things - for my project (which does several hundred thousand transactions a day) two load balanced servers with the business service tier as a DLL was sufficient (also we could reference that DLL in any other project).
cfeduke
Oh yeah and Linq to SQL over WCF = a mess.
cfeduke
A: 

Agreed with previous poster. You'd probably want to do this to apply the "Separation of Concerns" idea...

Joe The Software Developer
+2  A: 

Webservices became a separation layer because they were intended as a platform agnostic way of sending data to other software. They are websites that serve information to other software and not directly to the user.
A webservice is an overhauled separation layer for a website and can not completely replace a good data, business logic and UI separation.
Do it as your logic tells you to, but beware of the performance drops that you pay if you do not need to communicate to other software.

Ovidiu Pacurar
Yes there is definite overhead for using a web service middle tier, don't do it just because it sounds neat, do it only when absolutely necessary, and even then you'll still have your business logic in some sort of library.
cfeduke
+2  A: 

Completely agree with Ovidiu Pacurar. Web services are NOT a good choice for modeling layers of concern. You should do this using good old fashioned OO design. There is no reason for a web application to call web services within itself for data access unless they are intended for client ajax calls or if you need to run the business/data layer on another server for extreme security concerns.

DancesWithBamboo
And if its security concerns WCF is a better choice IMO (just a PITA).
cfeduke