WebApi and controller overflow

Question

I am starting to integrate WebApi and OData into a test bed application. Let it be simple and stick to one domain, Customer. Obviously I will have an MVC controller. The search gets its own view model (based on the Lucene index), so this will be a separate controller, right now the ODataController. But since the view / edit pages will have their own view models, they will be their own controller. It starts to feel redundant.

Trying to figure out a good design to make this work and still work with the idea of ​​a URL representing an object. Should the object in the URL be the Client and somehow I provide different views based on the URL parameters? Or should the client / CustomerSearch / CustomerEdit be different objects (which doesn't sound right)?

Answer 1

I assume that this WebAPI application will be a separate solution from the ASP.NET MVC solution that you are going to create. In a nutshell, WebAPI will be the business / domain level, and MVC will be the presentation layer.

So, speaking of the WebAPI solution, you only need one ApiController for the client example presented above. A view / edit request can have its own view models ... or not. Depending on how you create the view model, you can have one view model for clients or you can develop a hierarchy of client views in which the base view model contains data related to the search and the descendant view model fills in the details.

Your routing requests might look like this:

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

It looks like you will need two routes: one ApiController for the client and three request methods for what you described. I do not recommend a separate ApiController for OData, because functionality is object-specific.