views:

45

answers:

1

I'm currently working on a web service implementation to a combined web/desktop application (ie. access from different sources).

Now there are two questions I can't really find an answer to:

  1. How would I access the database in the right way (static class? singleton? DI?)? I didn't find any information on using a Web Service in a DI container to help with the database access.

  2. What about writing access? Is this the right way to offer a posibility of writing to the database? Of course, the requests would be protected with a userID and a key.

Note: this is NOT wcf, but the normal web service (ie. asmx file extension).

+1  A: 

There are many "right" ways of accessing a database from a web service. Personally, I often use ADO.NET inside a static class (or, more accurately, a class with a bunch of static methods) that generally returns a DataTable (wrapped in a DataSet, which can be serialized and thus easily returned from a web service). You could also use an ORM (like NHibernate), although these invariably have a larger overhead than ADO.NET and thus are a potential source of load problems on your server.

There's no particular reason not to allow write access to your database from your web service. If your application design requires that the database be written to (obviously a pretty common requirement) then it's perfectly fine to do so from the web service.

MusiGenesis
how do you solve concurrent writing access? just use a transaction in ado.net?
Femaref
Concurrent writes aren't particularly a problem in ADO.NET. You could have a situation where a subsequent user overwrites a previous user's data, but this is not a problem peculiar to ADO.NET or web services.
MusiGenesis
I agree with Musi: as long as you're ok with "last in wins" functionality, concurrent writes shouldn't be a problem. However, if your requirements are such that "last in wins" would be problematic, you'll want to look into techniques for either optimistic locking or pessimistic locking. Regardless of which locking scheme you implement, it will be more complex than a simple last-in-wins approach.
mikemanne
@mikemanne: my point was that concurrency issues aren't directly related to the fact that the database access is done from a web service.
MusiGenesis