views:

28

answers:

1

Anyone have suggestions how to architect the following setup: ASPX, IIS, 100s of transactions coming through the web pages and data which changes once a day & has to be processed at start-up (would be slow to reload & calculate from the database 100 times a day)

Currently we have:

  • ASPX pages running on IIS, communicating with
  • A windows Console EXE which self hosts a WCF service (we originally intended to make the console App a windows service)

The console service is started once per day with new data, which is processed and calculated and held in memory. During the day transactions (maybe 50-100 small xmls) are entered in the web and are processed by the Console App. There are only 3/4 APIs which the console exposes.

We would like to replace the console App with a DLL that offers the same functions (so we don't have to worry about stability as much) and have some questions as we are not DLL experts:

  • How can we persist data? We don't want to reload from the DB on every transaction. Can DLLs persist data? Or would we create a mini console app / service that would hold the persistent data?
  • Our Console EXE has a config file, how would the DLL access the config? Or is this bad practise? Is it also OK to access a database from a DLL?
  • If we were to stick to the Console EXE can we host EXEs on IIS? Or do they have to be DLLs? We will be using outsourced hosting

Or should we press ahead with a windows service that does the persisting & is easier to restart etc.?

A: 

Maybe I'm totally missing something, but why don't you just write a simple console application and schedule it with the Windows task scheduler. I think anything more is kind of overkill and since this needs to run once a day, it suits its purpose.

Pieter