WebApi and Controller overkill

Question

I'm starting to integrate WebApi & OData into a test bed application. Let's keep it simple and stick with one domain entity, Customer. Obviously I will have an MVC controller. Searching gets it own view model (based on a Lucene index), so that will be separate controller, right now ODataController. But since the view/edit pages will have their own view models, they'd be their own controller. This starts to feel like overkill.

Trying to figure out a good design to make this work and still work with the idea of the URL representing the entity. Should the entity in the URL be Customer and somehow I provide different representations based on URL params? Or should Customer/CustomerSearch/CustomerEdit be different entities (which doesn't sound right)?

Answer 1

I'm presuming that this WebAPI application is going to be a separate solution from the ASP.NET MVC solution you are going to build. In a nutshell, the WebAPI will be the business/domain layer and the MVC will be the presentation layer.

So, in speaking of the WebAPI solution, you only need a single ApiController for the Customer example you presented above. The view/edit request may have their own view models...or not. Depending on how you craft the view model, you may be able to have a single view model for customers, or you could develop a customer view hierarchy where the base view model holds the search-related data and the descendant view model fleshes out the details.

Your routing requests could look like:

GET - /Customer/                  retrieve multiple customers 
                                  (supplying OData parameters in query string)
GET - /Customer/{id}              retrieve a single customer
PUT - /Customer/{id}              edit customer

What it looks like is you will need is two routes, one ApiController for Customer, and three request methods for what you described. I don't recommend a separate ApiController for OData, because the functionality is dependent on a entity.