1

I know there might not be one simple answer for this, but i was hoping if somebody can point me in the right direction...

We have an ASP.NET webforms application with its own MS SQL database at our company's office, but now we want to show some data in this application from another MS SQL database, which is not at our company's office. We need to request the data server-side, so not directly from the webbrowser.

We don't want to use a direct sql connection to this remote database, but prefer to create a service which can do some business logic before returning the data. Business logic is very simple (such as retrieving some values end returning the average).

A couple years ago we did almost the same by writing a WCF service with a BasicHTTPBinding.

But now, after doing a couple hours of research, i'm a little bit confused about whats the best approach?

  • WCF Service
  • WCF Data Services
  • ASP.NET Web API
  • SignalR

Maybe somebody can give me some good tips?

Jeroen1984
  • 1,616
  • 1
  • 19
  • 32
  • SignalR doesn´t belong in this list. It´s possible to use it within any ASP.Net WebSite/Service/... – Jobo Jun 26 '13 at 09:34

1 Answers1

0

You're looking for machine-to-machine communications, in which case WCF still beats the rest in my experience.

You simply define data contracts for the entities you wish to exchange and happily code your logic in the WCF service. Then you generate a client, apply the proper binding (given machine-to-machine, net.tcp looks like an efficient candidate) and off they talk.

As for the rest: WCF Data Services - works nice if your data model matches the database model, which hardly ever is the case. When you need custom operations or wish to return different entities than database entities, Data Services are more cumbersome than plain WCF.

ASP.NET Web API and SignalR are mainly meant to consume from a browser. It's harder to generate a strongly-typed client for those.

CodeCaster
  • 147,647
  • 23
  • 218
  • 272
  • I have to disagree with the "Web Api is meant for browsers" part. Web Api is great for its simplicity and the ability to write REST or RESTful services, making your service easily accessible for a lot of clients. In a closed environment this may be no issue though. – Jobo Jun 26 '13 at 09:40
  • @Jobo please name _one_ framework that allows you to strongly-typed consume data from a REST service from .NET, so you can send an object from Web API that the other party can deserialize as easy as ~~possible~~ WCF. – CodeCaster Jun 26 '13 at 09:41
  • Thank you for your answers. This confirms my own thoughts. Guess i'll just create a simple WCF service, and forget about the others for now, since it is in a closed environment (no 3rd partys involved) and strongly typed data is required. – Jeroen1984 Jun 26 '13 at 09:42
  • @CodeCaster Surely WCF is good fit here, im just saying that, provided a documentation, Web Api allows for a lot more different clients and is by far not only meant for browser consumers. I would rather write a client for a REST service than deal with all the overhead WCF usually brings. Just my opinion and again, im not saying WCF isn´t a good choice here. – Jobo Jun 26 '13 at 09:50
  • @Jobo and I don't have anything against REST as well, my question was sincere. Both options have their place, and true, adding web and other clients later will be easier with REST. It's just that I love the code generation of WCF so I don't have to concern myself with boring (de)serialization code. – CodeCaster Jun 26 '13 at 09:53