WebAPI ODATA —使用标准控制器/ Ioc /存储库/ UoW排序体系结构与MVC一起使用

Question

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...

Answer 1

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.