Search code examples
c#wpfheadless

C# class with optional GUI?

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.

Solution

  • 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 :)