C# class with optional GUI?

Question

I am looking for a way to have a C# class, primarily run without any sort of GUI as part of a Windows Service to optionally be displayed on a WPF Canvas control.

My initial thought was to just make the object extend a WPF Control, however this would require the server-side (Windows Service) to have those libraries referenced, which isn't ideal. My second idea was to implement a Factory pattern whereby a wrapper would generate a GUI for the object, however I'd like the object to be able to define it's own design (XAML with codebehind ideally) if desired.

These classes are loaded via MEF from a plugins directory and instantiated based on an XML-based settings file.

The possibility of just having two separate classes had also crossed my mind, but this seems to add complexity and redundancy to the plugin making process (there will likely be several of these).

Thoughts?

EDIT: The classes can be thought of as Windows Workflow Foundation Activities. They are configured via a GUI and run on a server.

Answer 1

Separate the "business logic" of the class itself from any GUI of it. The GUI should just be a view (possibly with interaction) on top of the business logic.

As an example, I recently gave a presentation on "Skeetris" - a block-dropping game which might look familiar to some people. I have several projects in the solution:

Two projects which everything else references:

• Skeetris.Common (bits not actually specific to Skeetris - they'd normally go in a utility library in a general namespace)
• Skeetris.Model (all the actual behaviour - dropping and rotating shapes etc)

Client projects:

• Skeetris.Text (console-based version)
• Skeetris.Wpf
• Skeetris.WindowsStore
• Skeetris.Email
• Skeetris.Twitter

And testing projects:

• Skeetris.Model.Test (tests for the model)
• Skeetris.Model.Testing (a project with internal access to Skeetris.Model, designed to make it easier to test both the model and any code using the model)

As you can see, there's a wide variety of clients here - but none of them really "understand" Skeetris; only the model project does. The UI layer is as thin as possible, putting more logic into the model classes which are more easily tested.

This sort of setup sounds like an ideal fit for your project too:

• A "core" business logic project
• A Windows Service adapter project (with the code to respond to service events)
• A WPF project
• Test projects, of course :)

Answer 2

4sak3n0ne,

For this sort of requirement your best scenario would be using a minimum of 3 projects to achieve this result. You would have the following project system hierarchy.

• MyApp.Logic <- This is where your common class libraries are created.
• MyApp.Service <- This is your windows service library.
• MyApp.GUI <- This is your WPF GUI project.

Now given the project hierarchy (probably more and advanced than this) I would then reference the MyApp.Logic to both the MyApp.Service and MyApp.GUI projects.

This gives you clear separation between your logic, front end gui and windows service while still using the same code base. This also makes it easier to understand what each part of your solution does and allows for re-use of the same logic code base.

Cheers.