views:

39

answers:

3

Is there a business case for using WCF WITHIN your web application (ASP.NET/SQL Server)?

I'm not talking about a service to be consumed by others, but rather a service to be consumed WITHIN the web app. So far, the only use for web services WITHIN the web app I came up with is when I need to call the database from the client (through AJAX).

Please don't give me the copy/paste lesson on web services, all I'm looking for is a CONCRETE EXAMPLE of WCF benefiting the web application, and NOT the other apps consuming the services.

Quick clarification: by "web application" I mean a self-contained CRM of sorts. It does a lot, but it DOES NOT talk to any external apps/db's, and DOES NOT need to have service points open for other apps to consume.

+1  A: 

We have a Windows service that gathers live data from the web. Because the data is ephemeral (it's only really valid for around 3 minutes), there's no point in recording it in a database. To retrieve data, the Windows service offers a (TCP transport) WCF interface which is only exposed to the web-server, from which our web-app requests data.

spender
+1, this is a great example, and exactly the type of scenario I was looking for. Thank you.
roman m
But that's two applications - the windows service app and the web app...?
Murph
+1  A: 

I think it very much depends on how you define "application".

If you're talking about a single web application then with the exception of provision ajax data as you've already noted I'm struggling to think of a generic reason why you'd want to as a web service (even more so for WCF) is just an exposed API and if you're in the application surely it would be better (in all kinds of senses) to go straight to the API without the additional overhead of wrapping and unwrapping the calls and the data - which is pretty much redundant.

On the other hand if by "application" you mean an assembly of "stuff" that delivers a solution to a set (or even various sets) of end users then yes, of course... there is definitely a case where the flexbility of having components communicate via services outweights the overhead issue. Where it gets grey is if there is an assumption that a single application will (or at least might) later become multiple applications wired together - but if you're not doing it now then you're just causing yourself pain you don't need so shouldn't bother. If you need to split it deal with that as a self contained exercise as and when you need to split it.

Murph
by "application" I mean a single web application. a self-contained CRM of sorts.
roman m
In which case, and others may disagree, you might as well - probably *ought* - go straight to interface you'd use to define a WCF service rather than out to the service and back. And there's the key I think, that you may well slice the app up as if it were a number of distinct apps (for all the usual good reasons - separation of concerns, logical tiers, etc, etc) but calling the interface/API as a service merely adds overhead and complexity not needed within a single app
Murph
+1  A: 

One concrete example from my practice: On one web site we use actively tables which are implemented with respect of jqGrid plugin to jQuery. The contain of grids will be loaded per ajax. So the most pages of the web site are very simple and have clear XHTML code. The business logic with the interface to the database is inside of WCF service. Inside of WCF service we get data also from other information stores of the organization. In the same way if one will need later to have an input from our project the WCF service will be perfect.

So the usage of WCF WITHIN in our web application helps to archive clear interface, clear separation business logic from the HTML markup and better testability (with utit tests integrated in Visual Studio).

Oleg