is it better to retrieve data using web service or directly from database in .net

I was wondering which thing is better from below two...

1. retrieve data by creating webservice
2. create database connection from code behind开发者_StackOverflow社区 call stored procedure and retrieve data

Can anyone one explain how it differs?

Well, if you have no reason to use a web service then don't. It's always better to remove unnecessary layers when you can and go directly against the DB (via separate class library of course) if you can. There's really no reason to use a web service just for the sake of using it.

A web service is useful if you are going to be spreading code across servers for better scalability. But if everything is going to be running on the same server, there's not really much advantage in the extra complexity involved with a web service. If you want to layer your code, you could just as easily create a class library for the DB code.

Using the web service adds and extra step, because the web service will ultimately need to connect to the database to retrieve the data. Using a web service is a trade off. You are ultimately sacrificing some speed for additional abstraction between the UI and the database.

The web service adds a layer of abstraction between the database and the website. The website won't directly know what is going on at the data layer allowing the web service layer to transform data and apply business logic that the web site (or UI layer) doesn't need to be concerned with. If you are planning on having complex logic that is needed among several application web services can help with that since all the applications can connect to it, and it applies the necessary rules and transformations to the data.

Chances are, neither of your options are best.

I'd always avoid calling the database directly from code behind. Abstract out your database logic so that you have a layer of seperation between the consuming code (your code behind) and the code responsible for actually retrieving your data.

Having said that, using a web service as this "abstraction" only makes sense sometimes. Web services generally require data to be serialized for each call and are expensive for this (and other) reasons. Unless you need a web service (e.g. to allow access via http proxies and firewalls) then think twice about this apporach.

Without understanding your use case, it may make more sense to have your data logic seperate (e.g. in a seperate assembly), but not behind a web service. You should investigate creating a "domain model" of C# objects, and having your database abstraction return these rather than returning the connection/data readers. You may also want to look at other tools, such as Object Relational Mappers (e.g. NHibernate) that can take a lot of the heavy lifting out of this work.

Web Services should be used if you want to provide data to a 3rd party vendor. It is mostly used if network boundaries and firewalls have to be crossed. In most scenarios accessing the data using SPs is a safe bet.

It's an architectural decision and depends what application you are building, how it's deployed, etc.

Typically it's a good design principle regardless of using web services, to separate using a model such as data, business logic and presentation layers.

As for web services, if for example your deployment is across a series of servers, with data access and business logic separated from the presentation, and the presentation is perhaps a public facing web UI, then you might want to put the web UI on a server that is firewalled from the underlying business logic and data layers (for security reasons). Doing this, it may be easier to present an interface to the UI layer in the form of a web service.

You may want to expose your business logic to other consumers as well, as an API for them to use, and a web service would be ideal here. If your UI was later farmed out to a 3rd party, it may be worth using a web service to expose the business logic interface whilst protecting the implementation. A web service also allows your UI to be language independent of the implementation.

It doesn't have to be that way though. You can expose an interface between the business logic and UI that isn't a web service. You might just be deploying all on one server or some internal deployment that doesn't need a web service and just decide that you have the asp code call direct into business logic / data access assemblies.

However regardless of web services, it's best not to just put data access or business logic code straight into the UI code. It ties your UI to specifics of the implementation, and makes it difficult to separate should you wish to replace the UI in the future.

I would never go directly to the database from an asp.net application. Always abstract your databse access into a seperate assembly. Then you will have the option of whether to call the data layer assenmbly directly or through a webservice.