Vibrant discussion about CSLA .NET and using the framework to build great business applications.
I was going through some of the examples on the new web API that is part of the asp.net mvc 4 beta release. Does CSLA fit with the Web API model? I'm new to ASP.NET MVC and am trying to figure out if I should consider the web API for use with CSLA. Thanks.
How do you want to use it?
I can see two ways it may be useful.
First, you can expose a web api that is backed by CSLA business objects. I haven't looked into this, but it makes sense to do this because a web api is just a service endpoint, and many people already implement their services (asmx or WCF) using CSLA objects. I expect the web api services will be very similar.
Second, the data portal might use the web api as a transport at some point. If the web api becomes the preferred model for communication or service hosting (over WCF) then it makes sense that the data portal would support a web api channel. That shouldn't really affect the way the data portal works - it would be another option in addition to WCF, asmx, Remoting, and Enterprise Services. (though to be fair, I essentially deprecated everything but WCF starting with CSLA 4).
I agree that Web API is becoming the preferred communication mechanism for non-enterprise scenarios, and for some enterprise scenarios.
The thing to keep in mind is that the data portal is an n-tier technology, so being "open" is not a design consideration.
It would be extremely easy to create a Web API data portal channel, and I may do this at some point. But it won't be RESTful or open. It will provide the exact same data portal behaviors you have today, by passing a binary byte array via a REST service.
For that matter, the data portal is an open architecture. You can easily implement your own transport channels (proxy/host pairs) to use any synchronous network technology of your choice. In other words you don't need to wait for me if you have a pressing need :)
I would recommend looking at the old asmx channel to see how I did that, because the Web API channel will work in essentially the same way - run the serializer to create a byte array, and pass or accept the byte array via the GET/PUT operations, then run the serializer on the receiving end to deserialize the byte array back into the object graph.
This hasn't been a high priority for me, because the REST people will hate what I'll do (with a passion), and it offers no value to anyone already successfully using WCF.
Hey Rocky, be a fan for a while now--geez... has it been a decade already??
Anyway--my two cents... wrestling one convention or practice in favor of another... relaxing constraints... I don't think that's what your community is necessarily trying to convey. Perhaps a comprise in that they are seeking a standardized interface with CSLA and WebAPI (perhaps OWIN/Katana based) which utilizes the CSLA (internal) mechanisms which improve the XMLSerializer issue, but interface such that when the XML or JSON serializers fail, simply issue up the best practice Http Status responses. Perhaps some extensions or helpers which help the controller authors interact with the back end a bit easier.
Long story short, I believe this can be growth and leveraging the best of both worlds while remaining true to the elements that make both widely accepted. Here's another thought, is it CSLAs responsibility to police (perhaps too strong--and not intended that way) the full pipeline of contracts? I tend to believe that there are conventions (both existing and emerging) which can be tailored to meet the goals of your product and the goals of so-called modern architecture without compromising each other.
Does this make sense? Keep up the good work!
Something Rocky said in a more recent reply made me realize that I wasn't thinking correctly about my situation when I originally asked about the Web API.
"The thing to keep in mind is that the data portal is an n-tier technology, so being 'open' is not a design consideration."
This statement is extremely helpful. For my part, whether CSLA continues to use WCF or switches at some point to the WebAPI for its primary mechanism, it doesn't really matter in so far as it is taking care of the implementation for me. One less thing that I have to do...and since it is part of an n-tier application, I'm not particularly concerned with whether it meets the open RESTful standards.
The current beta of 4.5 includes a new HttpPortal for the data portal that does use Web API if your data portal server is MVC 5. If your data portal server is MVC 4 the host is just a controller. The client doesn't care which server technology you are using.
This is not strictly RESTful of course, because this is a data portal channel that uses the exact same semantics as the WCF channel (and the Local/asmx/Remoting/EnterpriseServices channels).
You can switch from the WcfProxy to the HttpProxy and the client won't care - which is the whole point of the data portal.
I implemented this new HttpProxy/Portal channel because the new Windows Phone 8.1 WinRT environment doesn't support WCF, so I needed a new data portal channel for that platform.
It turns out though, that by using the new HttpClient API from Microsoft we now finally have a consistent client-side API for calling services, because HttpClient (via NuGet) is available for all platforms.
"the new Windows Phone 8.1 WinRT environment doesn't support WCF"
Are you referring to WinRT universal apps? Also, is there a sample app showing the HttpProxy in use?
Universal apps yes, but the limitation is because WinRT on WP8.1 doesn't have WCF and universal apps use portable class libraries and those are limited by the lowest common denominator.
If you don't care about Windows Phone then this is a non-issue, but given my ongoing goal of making CSLA support all platforms it was something I had to take on as an issue.
The sample I've been using to test this (and some other stuff) is
At the moment the code is configured to use BrokeredProxy, which is a way for a WinRT app to use the data portal running in full .NET on the client device such that it can be called from a WinRT client.
But if you look at the two web projects you can see how the data portal controller is set up in MVC 4 and MVC 5 (page and web api respectively), and in the WinRT app.xaml.cs you can see the commented lines that configure HttpProxy on the client.
As you'd expect, the rest is transparent - your only concern (as always) is configuring the client and setting up the server.