How Can I Keep The 'GUI' Layer Out Of The 'Business Logic' Layer?

Question

I currently have a project that is a 'Business Object' project, and our goal is to have a clear separation between the GUI and the Business Objects. However, my project has a reference to System.Windows.Forms and that's a big red flag to everyone that my project is poorly designed.

My problem is that I'm using a 3rd party control called 'Active Query Builder'. It's literally a 'Control' as in GUI, System.Windows.Forms.Control; but it is never displayed anywhere, added to any Form's Controls collection. And it provides much of the core functionality of the Business Object.

Anyway, without the reference to System.Windows.Forms - I can't use the 3rd party control and the BO is horrifically broken. But I'm told I can't have a reference to System.Windows.Forms because it's bad coding practice.

And I'm at a complete loss for what to do.

Can someone with more design-pattern type experience offer up a solution?

Answer 1

So you have a library which references WindowsForms, but doesn't use anything directly? Your BO project is not messing around with any of the forms?

I think you're fine then, the reference is a red flag which says wait why am I doing this. But so long as the layer is still logically seperated then IMHO your ok.

One thing you could do is abstract this out into another project that would handle interacting with the query builder. So your BO project would work with the Query Builder project which would know how to use this control.

Answer 2

I may be wrong here but System.Windows.Forms is simply part of the .NET Framework and doesn't actually constitute the GUI. It may have many useful functions that you might utilise that don't display anything. I think whomever stated that this shouldn't be used might be misunderstanding the principle.

If you are developing an n-tier application it is common to operate GUI-Business Logic-Data Store separation but the GUI is strictly the user interface that presented to the user to allow interaction, not the framework that facilitates it.

Answer 3

I'm only vaguely familiar with Active Query Builder, but isn't that a GUI component that's used to create SQL queries? I'm at a loss to see how that sort of component belongs in business object at all.

Answer 4

You can create a wrapper class for the control that implements an interface with the methods you need. Your business object can have a dependency on that interface which can be implemented by anything (in this case it's a control).

It does raise some concerns that this "Control" has functionality unrelated to the UI; it just feels wrong.