Last post Oct 20, 2008 11:18 PM by pierslawson
May 12, 2008 07:37 PM|bcsmith100|LINK
I have a question about how to use asp.net MVC vs WCF web services.
I know that some of this is matter of the intended client.
For example if I am looking at mainly programmatic access I
would go for a WCF service. I can still provide views to this
service. As example of this is http://restchess.com/
This is a WCF service that has a user interface written for it.
See also http://www.code-magazine.com/Article.aspx?quickid=080014
about implmeneting "Rest-Based Services with WCF in .net 3.5".
Which concludes that WCF makes it possible to support multiple
service interfaces (json, html, etc), but requires a lot of work.
An MVC web application, since it incorparates views
is geared for (optmizes) human consumption rather than programatic
access, but I think we can also serve programatic access
through the Controller. This is the flip side of RestChess.com
when we have use cases that require both
human and programatic consumption. I can think of two cases
case 1) An Ajax application
case 2) Requirements for both programattic access AND
human views of the data and/or services.
Let's take case 1 first. From previous posts and investigations
I know that we can access the controller directly from the
AJAX call...thus treating the MVC controller like a web service
(at least within the limits of the single application).
The difference between case 1 and case 2 is who is allowed to
access the Controller. In Case 1 only the internal application
is access the controller programatically for the AJAX call.
In Case 2 I am allowing the web to access the controller programatically.
For Case 2 let's assume that I have data that I want to view
and also expose to authorized external programatic uses with
business partners (i.e. a pull-based electronic data exchange).
I have been thinking about this and it seems like the asp.net
MVC framework offers two ways to handle this
a) We could expose an action solely for the purposes
of programatic access and then use an actionfilter
to handle formatting requirements (xml, json, etc..).
I am unclear if this would work as the MVC interface
would still require a view that I would have to pass
Is there a way to bypass the view when
calling an action and just return directly from
b) We could expose an action in the controller that
is used by BOTH the programatic access and the
human views...but then map the action to multiple
views, where we use different VIEWENGINES to handle
the outputs (default for html, custom enginer for
programatic output). This has been covered by
several vidoes and articles. Here is one example:
All of the above is my current understanding. Please correct
me if I am wrong.
Now (finally) to my main question. It seems like the current
asp.net MVC implementation provides a way to handle the
combination of programatic and human access...but does not
provide the infrastructure to make it a common use case.
I don't mind writting the code, but one of the big differences
between the Java world and the Microsoft world (in the past)
is that completeness of the MS framework to do the common
I would hope that the MVC infrastructure would
provide multiple ViewEngines and that the common
programatic viewEngines (JSON, XML) would be part of the framework,
in addition to the HTML viewEngine.
I know that we can write these ViewEngines ourselves, but then
we have every application writting the same code that should be
in the framework.
Can we expect multiple viewEngines with the same
automatic data wire up (Viewdata) support to make programatic
access to the controller easily supported in a future release
of the MVC? Or is this something that the
application developer is always expected to handle?
Am I missing an easier way to expose a programatic interface?
May 12, 2008 10:56 PM|andyb.uk|LINK
I spent most of my early experiments with ASP.NET MVC attempting something similar to what you mention - one REST interface, multiple wire formats (XML, JSON, Atom or browser friendly semantic XHTML).
But there's a big problem. One spends so much time trying to invent a universal approach, the Interface, the usability of your Application, just becomes an after thought. The API just gets too clever.
One minor point is that some of the early approaches such as the very popular "Unifying Web Services" blog post might need revising with the advent of the ActionResult. Maybe a ServiceActionResult or RestActionResult, that could be rendered according to
Request Headers, bypassing the WebViewEngine as appropriate, as you mention.
More importantly though, I think ADO.NET Data Services (Astoria Team Blog) could be the key to save myself and others from trying to build a REST/Data API from scratch, and trying
to hack this onto MVC.
It's exciting that the Entity/Data picture from Microsoft is getting pretty clear. It highlights that ASP.NET MVC is definitely as you mention "optimized for human consumption".
May 15, 2008 05:11 AM|bcsmith100|LINK
Thanks for the post. Between my job and investigations of MVC I had not looked into the Entity Framework or Astoria. After reading your post I have spent the last few days looking at both. I now believe that you are right about the Entity Framework
being the key to this problem. From what I have read I am not so sure about Astoria. I have an asp.net 2.0 application using ObjectDataStores. I have hit limitations on the way all things in the ODS must be viewed in order to work nicely. I think this
might be a problem with Astoria as well. I will have to look into this as soon as I can get everything working on the machine I will use for running the 3.5 sp1 beta.
Even in the worst case scenario where I have to use both Astoria and MVC implementations to programmatic / human access to the data the use of the entity framework provides a place to hold all of my BLL / DAL layers so I am only working on the presentation
and some controller code. This is not bad.
Oct 20, 2008 11:18 PM|pierslawson|LINK
blog I have been looking at developing RESTful web service using the latest version of MVC. I use a format variable in the query string to dictate the representation returned. XHTML uses the standard ViewResult, JSON use the JsonResult and XML use an XsltResult