I’m writing a web service for some physical visualizations of data we are collecting and showing as part of a project we are running locally http://tenisonroad.com/ Some of the visualizations will be screen based and some will be physical (e.g. page 25 of this presentation from Resonate 2014). One thing my web service will do is signal to the visualizations when to change dataset. To do that I have a single integer, DemoDataSetsDwellTime
. I started off in SQL thinking to add this value amoung my existing table declarations, e.g.
CREATE TABLE ActiveDemoDwells
(secondsDwell INT NOT NULL)
But this seems wrong – why make a table that is only ever going to store one single number, one single record.
So then I thought of using application settings in the Web.config file
[Route("api/getdemodwelltime/")]
[AcceptVerbs("GET", "POST")]
public int GetDemoDwellTime()
{
return Int32.Parse(ConfigurationManager.AppSettings["DemoDataSetsDwellTimes"]);
}
with corresponding entry
<appSettings>
<add key="DemoDataSetsDwellTimes" value="20"/>
</appSettings>
But I have realised (from this answer) that the settings file should not really be used for writeable data, it is more suited / intended for read-only settings.
So finally I thought about using a simple flat file, i.e. something like this
[Route("api/getdemodwelltime/")]
[AcceptVerbs("GET", "POST")]
public int GetDemoDwellTime()
{
var lines = File.ReadAllLines("settings.txt");
var dwellTimeLine = lines.TakeWhile(line => line.StartsWith("dwellTime=")).FirstOrDefault();
int result;
return (dwellTimeLine != null && Int32.TryParse(dwellTimeLine.Remove(0, "dwellTime=".Length), out result)) ? result : -1;
}
But that may get in a mess in the (unlikely) event that get and set methods are called simultaneously (I think, I’m not sure how web servers manage local file system access).
So, which of these is the ‘correct’ approach, or is there another solution that I have overlooked?
- Store the single readable and writeable value in its own table in a database,
- Store it as an application setting in the Web.config file, or
- Store it in a flat file.
- Other. How about a static variable? Singletons don’t play well in the web environment, but that may work to your advantage. See also Asp.net session variable.
Another thought – you’re right about a one column / one record table, but if you already have the infrastructure set up to read & write tables, then the additional “cost” for this one would be pretty small. It would be easy to maintain since it’s using the same logic that everything else uses.
1