Is it common to delegate most of the legwork to Windows services?

  • Thread starter Thread starter Water Cooler v2
  • Start date Start date
W

Water Cooler v2

I want a process to be running always and it is supposed to do a lot of
stuff like:

1. reading and writing to files
2. watching a file system folder
3. communicating with COM components
4. communicating with other C DLLs
5. Watching for email from a POP3 server
6. Sending email using SMTP
7. Fetching data from SQL Server
8. Writing data to SQL Server


Is it common to have a Windows service directly do all this? Or would
it be better to make a regular exeucutable that is hidden do all this?
Or could you recommend a better architecture?
 
Not enough information.

If you want a process to watch something. a windows service is a good idea.
If you want to have something go off on a regular cycle that is not
conducive to the standard windows scheduler, a service is a good option.

As for whether all of the functions are wrapped or some are setup as pieces
of software that are fired by the service (web service front end, COM+,
executable) is largely dependent on your needs. In most cases, you will find
few items that need to be wrapped up completely in a service.

Hope that helps.

--
Gregory A. Beamer

*************************************************
Think Outside the Box!
*************************************************
 
What I do is this:

I still write "business layer" objects. I write objects... and don't really
consider the windows service part of it.

I start with an Interface

interface IWorker (or something like that .. it doens't matter)
the interface has 2 methods

StartWorker
StopWorker


Then I write a object which implements the IWorker

SmtpWorker : IWorker

//implement StartWorker
//implement StopWorker


...


Ok.... Then I'll write the windows service.

The windows service has its own Start and Stop methods.

I actually use reflection to construct one of my IWorker's .. which in this
first case is SmtpWorker

When the windows service code kicks in (the .Start method..) it will call
the IWorker.StartWorker method.

...

The reason I do this .. is that my WindowsService code is alot cleaner.
And if I ever need a scheduled task, all I have to do is write a quickie
console app.
I put NO logic whatsoever in the windows service. Just the code to create
any of my IWorker's...
and to call its methods.

I use a config file to house my reflection information

See my blog:
http://spaces.msn.com/sholliday/ 12/1/2005 entry

#3 is what I'm talking about.

The other advantage of the IWorker interface. is that if I need 3 different
functionalities to work with my one windows service...then I can just create
a collection of IWorkers,and call the StartWorker on each of the items in
the collection.
this is where the OO... and polymorphism of the methods makes things really
nice.
.............
 
Back
Top