Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
Switch to WPF and use MVVM problem solved ;) –  Mike Brown May 1 '12 at 14:40
    
You have 3 good answers. Why not pick one. –  KingOfHypocrites May 7 '12 at 15:32
    
sorry, was a bit busy lately. I want to study and understand INotifyPropertyChanged before I accept it. –  lulalala May 8 '12 at 2:09
add comment

3 Answers

up vote 1 down vote accepted

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.

Look up "data binding" in .NET. That seems to be what you're after. It's handled differently depending on whether you do WinForms or WPF, but the concepts are the same.

Your idea on the approach you need to take is basically right, however you probably don't need a RuleListWrapper class (at least not in this specific case). Through data binding your cell changes will automatically update the corresponding rule. Then your rule can raise a property change event to be handled by your result form.

Specifically, look up the System.ComponentModel.INotifyPropertyChanged interface for your rules. If you're using WinForms, look up BindingSource for the UI, and for WPF just look up the built-in binding syntax.

share|improve this answer
add comment

By core do you mean business layer, presentation layer, etc? By presentation I don't mean UI. Depending on the pattern, the UI might raise events to the presentation layer who would then interface with the business layer. Typically your middle tier will respond to UI events and communicate back with the view via a viewmodel or through an interface (once again depending on the pattern). If it is truly a core model in the utility sense, then I would say have a middle layer handle the events being raised and then call into the core model and back into the view.

share|improve this answer
    
yes the whole program is a small utility WinFrom application. Core is just like the utility API, which the UI(just a bunch of forms) will use. –  lulalala May 1 '12 at 13:45
    
Then use an intermediate layer to respond to UI events. This may be a controller, presenter, etc. It will then call into the utility and communicate back with the UI. The UI publishes the event... The middle layer subscribes, calls into the utility, responds back to UI. –  KingOfHypocrites May 1 '12 at 15:06
add comment

To keep concerns separate the core should not respond to UI events. That doesn't mean it can't respond to other events, generated say by the UI event handlers.

Keeping abstractions completely isolated is a difficult problem; sometimes there is only so much you can do. You may need to make the core interface aware of the existence of the UI, for example. But that doesn't mean it needs to know how the UI works. That can be taken care of by the UI/presentation layer.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.