Design – Interaction of a GUI-based App and Windows Service

Architecturedesignnetwcf

I am working on personal project that will be designed to help manage my media library, specifically recordings created by Windows Media Center.

So I am going to have the following parts to this application:

  • A Windows Service that monitors the recording folder. Once a new recording is completed that meets specific criteria, it will call several 3rd party CLI Applications to remove the commercials and re-encode the video into a more hard-drive friendly format.
  • A controller GUI to be able to modify settings of the service, specifically add new shows to watch for, and to modify parameters for the CLI Applications
  • A standalone (GUI-based) desktop application that can perform many of the same functions as the windows service, expect manually on specific files instead of automatically based on specific criteria.

(It should be mentioned that I have limited experience with an application of this complexity, and I have absolutely zero experience with Windows Services)

Since the 1st and 3rd bullet share similar functionality, my design plan is to pull the common functionality into a separate library shared by both parts of the application, but these 2 components do not need to interact otherwise.

The 2nd and 3rd bullets seem to share some common functionality, both will have a GUI, both will have to help define similar parameters (one to send to the service and the other to send directly to the CLI applications), so I can see some advantage to combining them into the same application.

On the other hand, the standalone application (bullet #3) really does not need to interact with the service at all, except for possibly sharing a few common default parameters that can easily be put into an XML in a common location, so it seems to make more sense to just keep everything separate.

The controller GUI (2nd bullet) is where I am stuck at the moment.

  • Do I just roll this functionality (allow for user interaction with the service to update settings and criteria) into the standalone application? Or would it be a better design decision to keep them separate? Specifically, I'm worried about adding the complexity of communicating with the Windows Service to the standalone application when it doesn't need it.
  • Is WCF the right approach to allow the controller GUI to interact with the Windows Service? Or is there a better alternative? At the moment, I don't envision a need for a significant amount of interaction, maybe just adding a new task once in a while and occasionally tweaking a parameter, but when something is changed, I do expect the windows service to immediately use the new settings.

Best Answer

I would recommend you look at ASP.NET MVC instead of using WCF. ASP.NET services are generally easier to setup and get running, and it doesn't sound like you need the additional complexity that WCF can offer. If you're concerned about security, run the ASP.NET services over https and that should be good enough for your usage.

For the controller that you described, it's really up to you to decide on what it needs and how to structure it. If you're worried about adding unnecessary complexity to one of the two UIs, then don't do that. You can always add that functionality later on when it actually is required. Get it working first before you worry about adding every last bell and whistle into the application.

You'll get to a point while building the application to where it will either make sense to keep the two UIs separate or to join them together. You won't really know that answer until you get to writing the application though. You may find that one application with two tabs solves that particular issue for you.

Related Topic