0

Working with WebAPI ODATA services with javascript is not a problem... but what is a current recommendation to wrap the http calls (CRUD) to be consumed through a MVC5 application with a repository. Much of the guidance I see ultimately goes directly to the entity/dbcontext. I am looking for guidance which demonstrates the "drinking of your own Kool-Aid" and consuming the same ODATA (and it can be plain WebAPI, also) published externally to consumers of an application.

In my mind, I'm looking at this sort of flow: AppController (site1:443)-->AppRepository-->OdataController (apiSite2:443)-->OdataRepository-->DataSource

The secondary concern is that I don't necessarily want direct access to a datasource by any consumer--especially posts without being vetted and I don't want all (any) of the logic in the controller. I might be overthinking something...

kirkpabk
  • 428
  • 4
  • 7

1 Answers1

0

In order to extract the business logic from the controller I typically either push said logic down to domain objects whenever possible. If that isn't possible, then I'll create a class specifically designed to manage the logic in question, such as an interaction between two different objects.

If all else fails, then I'll have the interaction managed by a service. The classes might look something like the following: 

public class SomeApiController : ApiController
{
    public SomeApiController(ISomeApiService service)
    {
       this.Service = service;
    }

    private ISomeApiService Service { get; set; }

    public IHttpActionResult SomeMethod(int someObjectId)
    {
        // service manages the logic and either defers to the object in question or resolves it through some specialized class
        var result = this.Service.SomeMethod(someObjectId);
        return this.OK(result);
    }
}

public class SomeApiService : ISomeApiService
{
    public SomeApiService(ISomeRepository repository)
    {
        this.Repository = repository;
    }

    private ISomeRepository Repository { get; set; }
}

... and so on.

The idea being that the layers have no dependencies upon one another which cannot be resolved through the IoC container of your choice and that the dependencies only go one way. That is to say SomeApiService has no dependency on SomeApiController and SomeApiRepository would have no dependency on SomeApiService.

m.casey
  • 2,579
  • 17
  • 10
  • Very good--outstanding--post m.casey, but I probably didn't phrase my question correctly. I'm concerned about the best practice regarding a controller consuming services from another controller and/or remote service--namely ODATA-based Web API that is not created using WCF. Since, WebAPI really doesn't have metadata and ODATA metadata is quite a bit different, I assume that the handling of the CRUD is not going to be as clean. About the nearest thing I could find (wrapper-like) is here: http://stackoverflow.com/questions/22146823/asp-net-mvc-using-web-api-to-return-a-razor-view – kirkpabk Jul 22 '14 at 18:26