Event driven design and separation of core/UI logic

Question

I am new to event driven development, and I feel lost when I try to implement events that should pass the core/UI boundary.

In my program I have the following (example in c#):

UI.RuleForm   Core.RuleList     UI.ResultForm
Cell 1        Rule 1
Cell 2        Rule 2
Cell 3        Rule 3

What I want is: when a RuleForm cell changes, it will update the corresponding rule in RuleList. And when the RuleList changes, the resultFrom will be recalculated from the rules.

My current thought is that, in order to keep core logic separated from UI logic (i.e. core should know nothing about UI), core should then only generate events, but not processing events generated by others.

So I have to create some kind of UI.RuleListWrapper which can process RuleForm change events, updating Core.RuleList. RuleList in term should fire OnChange events that UI.ResultForm can use.

So in summary, my questions are:

I want to know if my reasoning and purposed implementation is okay or not, which probably means: should a core module be able to process events generated by outside UI Is my separation some kind of "mysophobia", or has it been done before. Are there other better approaches?

Answer 1

You set the mvc tag. In MVC you have a MODEL containing the data and the business logic (or domain specific logic, if you prefer). You have a VIEW which displays the data and accepts user input. The view contains a strict minimum of code. Finally you have a CONTROLLER, which ties view and model together and orchestrates the whole thing.

The missing part in your example is the controller.

The MVC pattern exposes a general idea but does not specify any implementation details. Therefore you will find implementations of MVC that working quite differently.

The model does not know anything about the view or the controller. Usually the view does not know the controller. The main challenge of implementing MVC is to find an adequate way to communicate between M, V and C. I think that it is a good idea to take advantage of object-data binding when working with .NET and directly bind the view to the model. (This might not be "pure" MVC, but this does not hurt anybody.) The model should implement INotifyPropertyChanged. It allows the model to communicate with the view and the controller without knowing any details about them. The controller can optionally subscribe to the PropertyChanged event of the model in order to take appropriate actions when a property has changed, like telling the view to enable or disable a control, for instance. The controller would also subscribe button click events of the view and trigger the appropriate actions.

The controller can also communicate with other controllers, allowing you to display the result of an operation in one M-V-C trio on another view.