breeze with asp.net web api, reporitories and UoW

Question

I just started using breeze.js, it looks wonderful, but there is something that makes me confused. I am a newbie, so I am sorry if my question is dumb, or does not make sense:)

In server side, I have some repositories and UoW, I am trying to create REST Service. But I want to consume this service from mobile devices like Android, IOS and also from my SPA (Thanks to John Papa for HotTowel).

My confusion is if I arrange my UoW according to Breeze like using EFContextProvider or saving changes by using

 public SaveResult SaveChanges(JObject saveBundle)
    {
        return _contextProvider.SaveChanges(saveBundle);
    }

instead of using

public void Commit()
    {
        //System.Diagnostics.Debug.WriteLine("Committed");
        DbContext.SaveChanges();
    }

1)Am I still going to be able to use my UoW methods (like savechanges) from my non-breeze controllers?

and

2)Am I still going to be able to use the Rest service from native applications in mobile devices(that does not use breezejs).

Answer 1

1) No you cant use breeze contextProvider.SaveChanges() in your other controllers.

contextProvider.SaveChanges(JObject saveBundle)

breeze server side expects saveBundle to be a json data created by breeze client side js.

2) Create any other webapi controller for REST with its own repository. You can't work with breeze's repository saveChanges without breeze client side js.

UPDATE: Breeze is raising so fast, they now have a BreezeSharp project. It can be integrated into your .net application. See Jay Traband answer saving changes to breeze web api from c#

Answer 2

@Didar is correct to observe that the JObject saveBundle is specific to the POST body sent by a Breeze client using the Web API out-of-the-box data service adapters.

I want to let you know that a Breeze client saveChanges method call can update a conventional RESTy service with separate PUT/POST/DELETE/PATCH methods if that's what you want to do. You'll have to change the client-side "data service adapter" to one that understands your server API ... or more likely write one that matches the peculiarities of your API.

Writing a custom data service adapter not a newbie task to be sure. We'll be showing how to do it soon ... but it won't be a newbie task ... more an intermediate's task.

My point is that it is there to be done, it isn't hard, and you can take comfort that it will be within your capacity to write by the time you need it.

FWIW, none of the code you're showing actually conforms to repository or UOW patterns IMO. You're showing perfectly serviceable starter code ... code that gets you up and running with a minimum of fuss.

Once you get going, you'd refactor so that references to contextProvider are no longer in your controllers. They'd be wrapped in a repository or unit-of-work component of some sort.

That's a story for another day.