Stack Overflow is a community of 4.7 million programmers, just like you, helping each other.

Join them; it only takes a minute:

Sign up
Join the Stack Overflow community to:
  1. Ask programming questions
  2. Answer and help your peers
  3. Get recognized for your expertise

I current am using ASP.NET MVC and a single Controller for an "API" of sorts. I am using a Service/Repository pattern called from each action method.

Similar to below:

Repository:

    public IQueryable<Order> GetOrders()
    {
        return from sqlOrder in DB.Orders
               select new Order
               {
                   Id = sqlOrder.Id,
                   Name = sqlOrder.Name,
                   Price = sqlOrder.Price
               };
    }

Service:

    public List<Order> GetOrders()
    {
        return Repo.GetOrders().ToList();
    }

Controller/Action:

    public JsonResult GetOrders()
    {
        var orders = Service.GetOrders();

        return Json(orders, JsonRequestBehavior.AllowGet);
    }

Everything is working great, however I'm considering moving over to WEB API and Async/Await

Similar to below:

Repository: (no change)

    public IQueryable<Order> GetOrders()
    {
        return from sqlOrder in DB.Orders
               select new Venue
               {
                   Id = sqlOrder.Id,
                   Name = sqlOrder.Name,
                   Price = sqlOrder.Price
               };
    }

Service:

    public async Task<List<Order>> GetOrders()
    {
        return await Repo.GetOrders().ToListAsync();
    }

Controller/Action:

    [ResponseType(typeof(List<Order>))]
    public async Task<IHttpActionResult> GetOrders()
    {
        var orders = await Service.GetOrders();

        return Ok(orders);
    }

First, are there any problems with this async/await and Repository pattern?

Are there any major downsides to using the raw MVC framework as an "API" of endpoints? Instead of using "Web API"?

share|improve this question

closed as primarily opinion-based by Daniel A. White, TGMCians, Unihedron, rene, gunr2171 Nov 12 '14 at 18:51

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

    
why the down vote.. its not opinion i'm looking for facts on why to switch to async/await – aherrick Nov 6 '14 at 14:18
2  
not the d/v'ter but your question could be interpreted as 'why should I move'. Maybe clarify/edit the last few paragraphs to clear this up a bit? – jbutler483 Nov 6 '14 at 14:21
    
There shouldn't be any downsides. The functionality is essentially the same, WebAPI just provides a more RESTful-API-driven semantic way to achieve the functionality. That same functionality can be achieved with plain MVC, as you propose. – David Nov 6 '14 at 14:27
    
Yeah. ver considered using something that - ah - has less work for more functionality? I mean, seriously, you follow the antipattern of "make sure my web api is as clumsy to use as possible because i require hundreds of calls for anything". – TomTom Nov 6 '14 at 14:28
1  
@TomTom Not sure I follow what you are saying except for the fact that there will be no WebApi.. – aherrick Nov 6 '14 at 14:30

You've pretty much answered your own question :)

By using async/await the iis worker thread can re-use a thread. Suppose your api is receiving 1000 calls / second. If your thread limit is set to 100 then 900 calls will wait idle untill a request is fully finished.

By using async/await however the threads will be assigned sooner to the 900 waiting requests and the load will reach your database sooner(and harder).

imagine you have a maximum thread count of 1, 1 db call which lasts 10 secs and a server that can start a db call from a webrequest in 50ms.
By using async you could fire up 200 db calls (1 per every 50 ms) vs 1 if you don't free up that thread.

As for your second question : most people don't do their data access inside their controller but it makes a very clean & simple to understand example.
If my project is simple enough(think grid screens) i even prefer using EF statements inside the controller vs creating a DAL layer.
Don't forget that EF is a repository itself, it even has a unit of work build in ...

edit
It is indeed a good idea to wrap your businessLogic in a seperate layer from your controller.
You could use services and expose a method per query you want to do but i've been down that road and i usually find that my services get bloated rather fast as developers make more and more methods as they see fit.

Lately i adopted the command query system. A query just returns data and a command just does something. The seperation helps to keep to code cleaner and developers put more thought into creating a whole new queryClass as they would when they create just a method(even though the impact is the same).

I usually make my queries a bit dynamic but not too much.
For example an OrderQuery could contain 2 constructors, 1 with customerID and 1 with typeID) the query would then apply a filter more or a filter less depending on how it was constructed.
If i needed say all the latest orders which have a sales value of more then X i would probably create a new query GetOrdersByValue.
This way the query itself can stay clean and focussed(which results in more speed and developers not reinviting the wheel because they recognise that their request should already exist).

share|improve this answer
1  
And right after i submit he changes his question ... tssk. Anyway, no problem to use async with repository pattern and web.api is a bit more forcing you to use REST where MVC is a bit more open(which is a bad thing if you want to make a solid API). – Kristof Nov 6 '14 at 14:32
    
Thanks for the answer :) so where the reason I want to go Service/Repo pattern is 2 fold. I can map the EF objects to POCO which is nice. Also, lets say I want to get Orders by: Type, For each Customer, etc etc, I can have Service methods clearly represent each of those calls. Thoughts? – aherrick Nov 6 '14 at 14:32
1  
Just being in the process of making the move I find command query with a mediator so much cleaner than service repository – Mant101 Nov 6 '14 at 15:13

Not the answer you're looking for? Browse other questions tagged or ask your own question.