How should I implement a UI for IsDirty using the Model-View-Presenter pattern?

Question

I want to have a save button that is only enabled when the view isdirty. How should I approach this?

My particular situation is a WinForms application using .Net 2.0. I have a service layer that the presenter calls. The service layer returns a screen bound DTO.

Is it ok to bind the view to this DTO and have the DTO implement an isDirty property? Or should I unload the data from the DTO into another object specifically designed for presentation purposes e.g. viewmodel?

Answer 1

The view should never be dirty. Only your model.

Then you can simply have an event that triggers when your model becomes dirty and one for when it becomes clean.

Answer 2

Well could you make all of your controls have auto postback on changes enabled where they call _presenter.MarkDirty() or some similar method.

Or you could allow the save button to be used but if the object is clean to then respond with a no changes made dialog or similar.

Answer 3

I agree with @Pace that only the model should be dirty.

I just want to add here (as this seems to be about .net) that you can use CSLA for the implementation of your model, and you get IsDirty funcionality (and a lot of other things) for free.

Update:

Is CSLA not about the business layer?

Yes indeed, but I think an IsDirty method belongs in the business layer. You speak of implementing an IsDirty on your DTO, but the moment you do that, the object isn't a DTO anymore (as it does more than transferring data).

Also, you could use CSLA as an intermediate layer between your DTO's and your presentation layer, although this would be a little too much overhead if your intention is only to use the IsDirty functionality.

The point is: The moment you start putting 'functionality' into your DTO's, I don't see why you wouldn't expose CSLA objects from your business layer in stead of simple DTO's.

Answer 4

Here is what I do, the view itself can track if the user has attempted to modify the data. When this happens it can notify the presenter that the view data has changed and the presenter can act on this event to enable/disable the save button. This is the simplest solution I have found so far otherwise you have to have change tracking on the DTO/Data object itself.