To gain some perspective, we’ve been using ASP.NET web forms for ages.
We’re also aware of the benefits of MVC over web forms, however an alternative option is being tossed around which is to bypass all of those abstraction layers and just go from a pure .HTML page to the WCF service.
No .ASPX, no .cshtml / .vbhtml, just pure .HTML files in order to avoid server side logic and rendering. That’s the idea being suggested by some, and is becoming more appealing with HTML5 and its features. The ability to target more devices by having full control over the HTML is also a driving factor.
I know that it’s feasible from a technical point of view – especially with jQuery making things so much easier – but I’m worried that by tossing the whole server side abstraction (code-behind in web forms, controller and view-binding in MVC) we’ll end up doing more plumbing which we didn’t have to worry about previously.
The question boils down to:
- Is that a valid concern, and if so what kind of plumbing might we end up doing?
- What is it exactly that we could lose by tossing the whole ASP.NET framework aside (from the web application’s side) and just relying on direct communication to our WCF service from pure HTML pages?
N.B: I used the term ‘enterprise level’ to emphasize that this is not a simple web-app with a few pages where the ultimate decision of the underlying architecture is irrelevant, we’re talking big ass app here 🙂
Edit: In order to be even clearer, the main areas that are of concern to us in such an approach are:
-
Authentication and Authorization –> MVC handles this in a very straightforward way with attributes (e.g. AuthorizeAttribute), this ‘static’ approach however means the WCF will have to handle tokens, encrypt/decrypt them, and decide who gets to do what all on its own while maintaining all of this information throughout every call. Is this the only solution?
-
Separation of Concern –> MVC clearly does that, and does it very well might I add. This approach however forces you to explicitly write in your HTML which WCF function call is needed. So not only is your presentation layer handling what to draw, it also has embedded in it the logic of what to call to get its data, and how to distribute it in the page. This may not be such a big deal, but in contrast the ViewBag in MVC gives you the option to have your WCF service URLs as a dynamic property, meaning that logic is now part of your controller and not your HTML page. Changing that logic exempts the hassle of going through HTML pages altogether.
-
Binding & Validation –> I’ve put these two in the same basket because ultimately once the WCF service responds with a JSON object containing all the info my page needs to function (including validation rules) someone’s gonna have to bind it to those idle controls.
Hope the idea is clear enough, and thanks in advance.
You haven’t “tossed the whole server side abstraction” you are partitioning the functionality differently from a standard web application. The server side abstraction now comes from the WCF service which is supplying data to the presentation tier
You will need to use Web style APIs to return JSON to make it easy to consume – and I’d suggest using the new Web API for that as it gives you fine grained control over the HTTP interaction that was somewhat hidden in previous REST implementations in WCF
Obviously going this route is not a silver bullet – you will still need to care about round-trips and latency (it would be very easy to have composite parts of your web UI making separate calls to the backend for data which ends up with pages very slow to render). But architecturally there is no reason that this approach is particularly less limiting than having a traditional web application.
Probably the one downside is that for each page there are going to be at least two roundtrips – one to get the HTML + JS and the other for the JS to get the data – with a traditional web app there is only one roundtrip to achieve the same as the data is loaded server side when rendering the page in the first place