Reputation: 17392
We're working on creating a Windows service to import/export data from various places.
Our service currently has methods like the following, each of which run in their own thread on their own timers.
ImportFromFoo
ImportFromFoo2
ExportToFoo
ExportToFoo2
In the long term, there are going to be 10+ different imports/exports, all running in their own threads on different timers. They are all far too specific to be made generic, as the data is sent and retrieved in lots of different ways and different manipulations are performed on the data for each import/export. What I'm trying to work out is if we are better off splitting the service up, so each import/export lives in its own service.
As far as I can see, the benefits are:
The cons are really just that there will be more projects/services to maintain.
I just wondered what other people's opinions were, and if having lots of little services rather than one bigger service is seen as bad practice.
All the services will be run on our app server so it's just us who has to maintain them, not the user.
Upvotes: 1
Views: 109
Reputation: 11090
I'm strongly in favour of creating multiple services. The only reason to not do that is if there was significant performance problems on the user's system from starting 10+ services instead of 1.
Separate services would allow you to:
I don't see the multiple projects as a problem, any good idea should allow you to manage and build them as one.
Upvotes: 2