Transactional objects in .NET [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answer开发者_如何学JAVAed with facts and citations.

Closed 2 years ago.

Improve this question

In user interfaces there is often a need to implement a cancel button when editing some entities. In WPF it would be nice if you could make your view model transactional. I will try to explain a little bit more in detail what I mean:

The view model is connected to the model and exposes data in a way that's easier to handle for the view (utilizing data binding). Changes to the view model result in changes in the model. However, if there is a cancel button you usually don't want to perform the changes immediately on the model, so I think of some kind of buffering changes. When you commit the changes, there are being transferred to the model, otherwise they are deleted.

Right now I have implemented a solution that creates a proxy of the view model which is bound to the view instead of the real view model. The proxy is not connected to the model but records changes to properties and method calls by using interceptors. There is a submit method which applies the invocations on the real view model. I think that's quite a good solution but it is still quite buggy (if the view model contains collections and so on).

I'm looking for a framework which does this kind of stuff. Are there any out there?

Best Regards,

Oliver Hanappi

---

You can take a look at the Cinch MVVM Framework by Sacha Barber.

It offers "IEditableObject usage to store/restore object state on edit / cancel edit"

---

BindingGroups aren't just for Binding validation, you can use a BindingGroup's BeginEdit, CommitEdit, and CancelEdit to enable transactional logic. If you're a pure MVVM type there's one thing that might be a problem for you - you will most likely get some code-behind in your views - otherwise it works like a charm.

---

You can disconnect one of the bindings, so that changes in the view are not propagated all the way to the model until you do it (manually). This is what you've already done. You could also allow the updates to go through, but then reload the object from the database if the user cancels.

Other options include implementing IEditableObject, to rollback changes: http://msdn.microsoft.com/en-us/library/system.componentmodel.ieditableobject.aspx This is not always pleasant when you are trying to make deep copies of nontrivial objects.

I think your solution is fine, but I'm curious why things get buggy with collections.