is there any progress on this one?

Patrick,
Yes indeed there are ways to intercept the save change method. Without that Breeze would be dead, isn't it?
You can override the SaveChangesCore method of EFContextProvider and do stuff that you wish in that method.

We have a multi-tiered architecture and we have successfully used Breeze in conjunction with the Web API layer. The Web API layer has no reference to EF or access to any Data access components. Heck we even have web models (DTOs) which are completely separate from our entity models. We use Automapper for mapping between entities. No matter what the folks say, in an Enterprise level application, I would never ever expose my entire core entity model to anyone outside. Period. It just gives away way too much information (some of which might be your USP).

I also believe Breeze should focus on the client side and make things easier (like creating Metadata, using proper REST convention for updates (rather than just one method) etc.). Having said that, Breeze makes so much easier for client side data management. It has reduced the client side complexity by orders of magnitude. And if you are planning for a SPA, not having something like Breeze doesn't make much sense.

Cheers,

Here is a particular use case where this would be beneficial (for me at least : ))

Assume that I have a web app that is using the Unit of Work and repository pattern. I want to define a specific save path when creating a new user (or requesting a user) so that certain tables that are not exposed to the client (specifically security information that resides on the server side only) have records created to allow the client to have a temporary user login security file created.

(There may already be something to provide this by intercepting the saveChanges, but if there is I have not seen it / been able to do it with a unit of work YET)

If I request a new user and call save changes, I am not able to intercept the new user to create it's temporary user security file. So far the only method I have found for this is to call save changes and then make an AJAX request to the server to create the security file, but that AJAX isn't a very secure / reliable way to request creation of a security file.

see similar request targeting REST using JSONAPI.org draft http://breezejs.uservoice.com/forums/173093-breeze-feature-suggestions/suggestions/4145588-json-api-ember-js-rest-support

This is really needed feature. It would be good to have this feature, I will definitely select breeze next time if this feature will be implemented.

Current implementation of breeze web api is great buttheart in real life projects. With current approach it's very hard to create even middle sized applications.
Full support for the REST will be very helpfull.

This is really needed feature, it will make life of developer much more easier!

I think the idea looks very attractive.
Default way of Breeze - to replicate heavy ORM between client and server looks suspicious - Internet channel could kill performance; or why should client ORM restricts my network interaction?
Idea with full REST support looks if not a required but logical in terms of follow well-known standard. Why to invent the wheel?

I am looking forward for this feature

Yes, this would be very useful

Hello John,

I agree with you that create one http method for all CRUD operations for web api is simplest way. But it's not correct in case if developer want to create real RESTfull service which is shared for some audience and used in own app.

About transactions.. I think that creating and commiting of transaction it's not RESTfull approach. So I'll agree with persons from this discussion http://stackoverflow.com/questions/147207/transactions-in-rest that one RESTfull request is corresponding to one transaction.
"In your request, you seem to be saying that the developer could use a REST API for saving a single entity, and a batch API (WebApi or OData batch) for saving all changes at once. This seems like the road to partial saves and all their problems." - not quite.

Imagine that our domain model consists from three entities: Category, Product, Price. Category can have many products. Product have Category and one or more Prices.

Let's imagine that we've created API for own usage and for some community:

GET: http://someurl/api/categories/1
POST: http://someurl/api/categories
paramns: {name: 'category'}
PUT: http://someurl/api/categories/1
params:.....
DELETE:http://someurl/api/categories

GET: http://someurl/api/products/1
POST:http://someurl/api/products
params: {name: 'product', prices:[{id:1, value: 100}, {id: 2, value: 200}]}
.....

Now we want create own app on base of this api and using breezejs. For now it's impossible.. For now breezejs will send every request as post method.

Let's look at way that I'm suggesting.

Situations:
1) a) User filled form for creating of category and clicked save. Breeze.js should check how many entities in unchanged state. If only one entity is in affected then breezejs have to send request with with post http method and data corresponding only to entity(without entity aspect or any additional info). Identity information should be updated from data which will be returned from request.
b) User want delete category. Breeze check the same condition and send request with DELETE http method. The same for update(put method)
2) User filled form for creating of products. Added two price entities to product entity in this form. Business rule is that manipulation with product and prices is one business transaction. Breezejs start checking count of unchanged entities and will find that there are three entities in 'added' state.
Breezejs must decide is it batch commit or it's one business transaction. In this case you have to add possibility for developer to mark manipulations with some entities as one business transaction(show somehow for breezejs that manipulations with product and prices is one business transaction with product entity in role of parent)
In this case breezejs will determine that all affected entities is one business transaction, find root(parent) object and create post data(for ex {name: 'product', prices:[{id:1, value: 100}, {id: 2, value: 200}]}). Then send one request with POST http method for creation. Identity information should be updated from data which will be returned from request.
The same logic for update/delete but with different params and http methods
3) Breezejs found that all affected entities are different business transaction. In this case breezejs can use existing functionality for batch saving in web api or odata depending on saveoptions.
In this situation we must add to existing API(for customers or products) supporting for one additional http method for batch saving. I think batch save will be used only in synchronizing of offline and online storages or in difficult requirements for app.

So if breezejs will be implemented in that way then developers will be able to create real RESTfull api, web app based on created api with breezejs and breezejs will use batch saving if it has need. And it's very neccesary to mark that developer have just to mark somehow that some manipulations with multiple entities should be handled as one transaction(it should be implemented) and breezejs will resolve other difficult situations.

I'm not arguing that it's not simple logic but if breezejs will support this then I think you won't have competitors :).

The reason we create a single POST for saves with WebApi is that it is by far the easiest and most compact way to send a complete bundle of entities to the server for the purpose of a save. However, nothing in Breeze is tied down to this. In fact, the Breeze OData adapter does exactly what you suggests, except that in order to accomplish it we have to create a multipart-mime message that internally contains a collection of put/patch and delete requests. The multipart-mime is necessary for transactional support. We do it this way because this is what the OData spec specifies.

In your request, you seem to be saying that the developer could use a REST API for saving a single entity, and a batch API (WebApi or OData batch) for saving all changes at once. This seems like the road to partial saves and all their problems.

I like the idea of supporting REST urls. Our WebApi implementation supports GET in a RESTful manner (e.g. /breeze/northwind/Customers), and we could add support for the getting a single customer via /breeze/northwind/Customer/4321.

Updates are another matter. The answers to this SO question about REST transactions imply that you should treat a “transaction” as its own resource. However, the answers disagree in the specifics. Some suggest that the transaction should first be created, then the resources added to it in separate requests, then committed in a final request. Painful.

http://stackoverflow.com/questions/147207/transactions-in-rest

We already give SaveChanges its own URL, to which we POST, which appropriately captures the non-idempotent semantics of the save.

This feature will be very useful. Hope it'll be implemented.

http://stackoverflow.com/questions/16315683/breeze-js-restfull-support-clean-and-powerful-asp-net-web-api-with-breeze-js