how to approach a class that is read only, but you still need IDataErrorInfo and INotifyPropertyChanged

pcanada posted on Thursday, October 11, 2007

I have a class where I cannot decide between inheriting from ReadOnlyBase or BusinessBase. The class has all readonly properties, however some of the data retrieved through those properties might be modified by business methods. When the members are modified, I would like the UI (databinded) to be updated, and I would also like the ability to use IDataErrorInfo to communicate back to the UI when situations arise inside of the business methods.

If I inherit from ReadOnlyBase, then I need to manually implement IDataErrorInfo and INotifyPropertyChanged. If I inherit from BusinessBase, then I dont have to implement these myself, but the business object has alot of features which are not applicable.

What if a business method doesnt modify a property, yet I still want to use IDataErrorInfo to communicate problems when objects are bound to a grid. Am I correct in thinking the UI has to call ResetCurrentItem() on the binding source after calling the business method?

robert_m replied on Friday, October 12, 2007

If you want to be able to change the data your class handles (and probably later save the changes) then it doesn't look read-only to me  - regardless of the way you change the data (via read-write properties or custom methods. If you inherit from BusinessBase and add some validation rules and invoke PropertyHasChanged("<propname>") in methods you use to change data, all should work fine.

So I would say BusinessBase would be better choice...

ajj3085 replied on Friday, October 12, 2007

So you have a readonly object, but it polls occasionally to see if there are any changes?

If that's the case, your best bet is to inhert BusinessBase.  It has everything you need implemented.  You don't need to create any writable properties just because you inherit that class. 

You don't need to worry about the other features you're not using.  Set the grid to disallow updates, and I don't think it will call BeginEdit so n-level undo will never take any resources.

HTH
Andy

pcanada replied on Friday, October 12, 2007

Thank you for the replies!

The class will not be modifying its properties and then need to persist the changed data to a database.

The objects are in a collection that is bound to a grid.
The class has a couple methods that interact with the environment, for example, one method opens and manipulates a file on disk.

If the method call is successful, the class toggles a boolean property (which is not persisted to a database), and this property is displayed in the grid, so I need the UI to be notified that it has changed.

If the method call fails, the boolean property will NOT be modified (remains false), however I need to communicate the problems back to the UI. IDataErrorInfo seems like a nice way to achieve that, since it will place an icon in the grid and the text can list any/all problems that might have occurred. However, the UI must be instructed to fetch the DataErrorInfo on each item in the grid, since no properties have been modified upon failure.

So the bottom line is that the class is read only except for a single boolean property which is not persisted anywhere, so there is no need for the business object to save itself. Either approach seems to have its pro's and cons.