The next trick in Add OpenAccess Service Wizard sleeve - Web API

by OpenAccess ORM Team | Comments 7

Telerik OpenAccess ORM Q2 2012 is already live so hurry up and check all the benefits of upgrading to it on our What’s New page

One of the most interesting additions to this release is the Add OpenAccess Service wizard (in short AOS wizard), a great time-saver when you want to expose your data to other tiers using various kinds of services. After implementing the generation of WCF Data Services 5 there, we would like to share with you our future plans for this wizard – Web API support!

Goals

As many of you know Microsoft recently published a release candidate version of the new WebAPI with the MVC 4 RC. We think it is the perfect moment to add one more service layer technology to the broad array of service types generated by AOS wizard.
As with the other service scaffolds, the main goal is to let developers hit the ground running with a new service implementation. That means we need to expose endpoints for each entity, and related methods for creating, updating and deleting them. In the case of WebAPI, we will also need to configure service routes in the global.asax.

Challenges

The WebAPI framework makes it easier for developers to create and configure a service layer for any application, but some of the same challenges must still be faced. In particular, how do you best expose your data at the service boundary?

In a well-designed data model, entities have many relationships which can wreak havoc on a JSON or XML serializer. To get around these issues the Add OpenAccess Service Wizard creates repositories and DTOs for each entity. While we believe separating the data layer and the transport layer is a good thing, we consider allowing the developers to make that decision based on their specific needs. We will provide an option for that.

As always, the AOS wizard will generate the service end points using T4 templates, which can easily be customized. That said, we hope that by starting the conversation early we can make the default functionality robust enough that most developers will not have to customize anything :)

Conclusions

In the end it is YOUR feedback that matters most!

What would you like to see the Data Service Wizard scaffold for WebAPI out of the box?

Are you going to replace any of your existing WCF services with WebAPI?

Would you like to see navigation properties support in our DTO types in the WebAPI service layer?


Happy Coding!

Team Lead
Telerik OpenAccess ORM

7 Comments

Don Price
I plan to use WebAPI from this point forward; of course, I may not always have the option available to me (per my clients), but I will do my best to convince the client (and team) of the benefits. I hope to see standard support and practice for navigation properties in DTO types within this layer.
Great stuff...thank you!
John Burrows
Same again.  WebAPI all the way.  
Yes i want to see the scaffold out of the box
I don't have any substantial existing WCF services so will not be replacing them
My main goal is to be as enterprise as possible with strict design patterns and maximum flexibility even if it introduces a little extra overhead.  DTO seems the way to go to me.
John Burrows
One other thing.  Although my first WebAPI app will be standalone.  As a DNN developer I would like to be able to build modules for DNN using WEB API (in the roadmap for DNN) and Telerik ORM so anything that could be done with the Service Wizard which aids this process would be good.  I would imagine it would be similar to building modules for Sitefinity that use this stack.  
John Burrows
And another thing :)
I would like to see examples for these new services and Kendo UI.  I know it should just flow through but just want to raise the connection.  I "think"  the  two in combination are going to be the future path for my apps and probably others
John Burrows
OK One more.  Currently in the ORM SDK you have a n-tier example for WCF and Plain forms.  I would like to see an SDK Sample for
n-tier + ASP.NET Web API + Kendo UI
Telerik Admin
We are planning to use the same (or similar) service layer stack as the one used in Plan WCF Services. It will include generated DTO types, Assemblers and Repositories.
In additiion we have created a generic base controller for the Web API Controllers and very minimal implementation for the concrete per entity type controllers derived from the base one.
One additional question:
How do you feel if we patch automatically the Global.asax.cs/vb code file in order to register Web API routes with ASP.NET?
Serge
For the moment we aren't planning any client side code generation, so the best we can do is generate a web api service, which will be however easy to consume with KendoUI. 
As soon as we have that in place, we will certainly provide an SDK example for Kendo UI (most probably a Sofia Car Rental one).
The OpenAccess team

Comments

  1.    
      
      
       
  2. (optional, emails won't be shown on public pages)
  3. (optional)
Read more articles by OpenAccess ORM Team - or - read latest articles in Developer Tools