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