Web services vs local functions

Question

In order to develop an Information system, my system will contain web, mobile and desktop applications. My idea is to make one web services , because for mobile phone apps it will be better to use a web service to manage database and do the heavy width processing also to reuse code in other apps.
In other hand for the desktop and web application I was thinking about using web services.
My questions are:

• for a start we will use one server to manage the database and web services, we will have a good server, is it possible to have concurrency acces problem.
• Does the local mehtods will to the desktop application to run faster?
• I will use .Net farmework, is it wise to use oData in my case?
• Is there a better way to do build this system.
  

I'm open to any suggestion

Answer 1

I would implement all the logic in a separate library (let's call it api.dll) not bound to any transport, so you could use it wherever you want. I mean, if you make a web API through http, there will be some controllers calling api.dll methods to serve the responses. But you could also reference api.dll from your desktop app and use it directly without having to make http requests to the web api (slower and more complicated). And tomorrow, if you decide to change the transport of the web services from http to websockets, there is no much work to be done except of calling api.dll methods from the websocket. You won't have concurrency problems. Use async programming whenever you can, including controllers. This way you'll serve more requests with the same number of threads. Regarding OData, it's a matter of taste. I personally don't like it. It feels like a magic box solution, you end up without a well defined API. But again, it depends on the use case.

EDIT: I can't comment on @RubberDuck answer so I'll answer here: The idea is to not implement anything in the controllers except the call to the shared library. The single source of truth is the shared library.

Answer 2

If you need to expose a web service for one of your clients, then all the clients need to access the data through the web service. You're going to want a single access point to your data. Otherwise, you'll inevitably have some important business logic in your web service's controller that doesn't get propagated to all the clients of the data.dll or, worse, you have a bunch of clients working around the same problem in inconsistent ways.

The whole point of a web service is to decouple the client from the database and easily be able to access it easily via a single source of truth. Going around your service for some clients, but not others, is going to cause someone a fairly large headache eventually.