BCF Documentation

Coding smart object-models begins easy and becomes more and more difficult. Most you have to add some techniques hard to combine. Named:

• Computed properties
• Validation
• Change notification
• Undo and redo
• Transaction and sub-transaction processing

• "Computed properties will be computed in getter." - This means on each property get the result will be computed. Having large models or complex structures like trees you will encounter performance issues and possibly stackoverflows. This means also there is no changed-event to update bindings. It works in many cases - accidentally. For example: computed columns in System.Data.DataTable computes and raises changed-event in getter. So bindings will not update UI unless any other value of same row is updated.

  "Caching values and forwarding changes". Caching will not prevent stackoverflow caused by large or complex models. Forwarding changes causes a new performance issue. Example: your invoice-model has a DiscountPercent and a Total (SUM(invoice-items.Total)) property and invoice-item-model has DefaultPrice and Total(DefaultPrice*(100-invoice.DiscountPercent)/100) properties. So updating invoice.DiscountPercent will cause recalculate each invoice-item.Total and each invoice-item.Total will cause recalculate invoice.Total. So invoice.Total is calculated COUNT(invoice-items)-times. This becomes really funny when each change will force an UI-update.

  It would be nice to have something like a BcfTransaction that manages calculation order so each value is computed when it has to be computed and only once - maximum.

• INotifyPropertyChanged change notification is the way WPF/XAML databinding works and it works great. Simple apps with data-model == business-model == view-model can be build very fast. When a simple app becomes a complex one you may encounter the 2nd issue above and have an ugly calculation-UI-update-loop task. Different requirements on change-notification is one reason for using a distinct model layers.

  It would be nice to have something like a BcfTransactionCreateChangeSet where I can get the changes made. And a pony. And an automatic updating BcfViewManager for WPF/XAML and one BcfViewManager for winforms.

• "Validation is not hard." Validation is hard as calculation. There are the same requirements on when and how often validation is performed like on calculation. Managing calculation dependencies is a BCF key feature. One of the most underrated issues is redundancy in calculation parameter access and change notification. A simple model property like Total (SUM(invoice-items.Total)) needs change notification from invoice-items collection and from collection items Total property. When adding change handlers in code or implement explicit calculation calls you define the dependencies twice. Maintaining those models becomes more and more expensive.

  It would be nice to have dictinct function (see Column: Settings/Function; Rule: Settings/Function) and parameter declaration (see Parameter: Settings/Access Path) for automatic value access and change notification.

• "Let's start without undo." Probably your model will get functions like create and restore snapshots. It becomes ugly when the model grows and restoring a snapshot takes more than one second. The key to undo/redo function basing on changes is transaction processing.

  It would be nice to simply enable undo/redo (BcfDataSetEnableMemoryUndo).

Business-Model

View-Model

Data-Model