# Boilerplate singleton / lazy initialiser

I'm working with an existing code base here and while I don't have the time/budget to re-do the entire thing (ultimate solution), I do get a bit of leeway to enhance the code base, as well as maintaining it.

We're using EntityFramework and the SynchronizedBindingList is essentially just that; it keeps all the data in memory, but also ensures that it's as in-sync as possible with the database. The idea being that memory is cheap and we'd rather use the end-users' (internal staff) memory, than have a few hundred users frequently querying the database. The concept works well and we haven't really had any issues with the setup, I'm just trying to make the code more maintainable.

At present, we have a lot of Manager classes, essentially one for each table, that has the following code:

public class LessonsLeartManager
{
private static readonly Lazy<LessonsLearntManager> Lazy =
new Lazy<LessonsLearntManager>(() => new LessonsLearntManager());
public SynchronizedBindingList<LessonsLearnt, DbContext> LessonsLearntList { get; private set; }

public static LessonsLearntManager Instance
{
get { return Lazy.Value; }
}

private LessonsLearntManager()
{
LessonsLearntList = new SynchronizedBindingList<LessonsLearnt, DbContext>();
LessonsLearntList.RefreshSync();
}

// Manager specific code goes here.
}


Obviously this is highly repetitive and difficult to maintain if you want to change something as it would have to be changed across multiple files.

I have been fiddling with this idea today and would like to get other opinions on the quality/idea of this code:

public class DatabaseTable<TManager, TTable> where TManager : class, new()
where TTable : class, IDbPk<TTable>, IAutoIncludeEntity<TTable>, new()
{
private static readonly Lazy<TManager> Lazy = new Lazy<TManager>(() => new TManager());
public SynchronizedBindingList<TTable, DbContext> List { get; private set; }

internal DatabaseTable()
{
List = new SynchronizedBindingList<TTable, DbContext>();
List.RefreshSync();
}

public static TManager Instance
{
get { return Lazy.Value; }
}
}


Obviously the previous LessonsLearntManager code then becomes:

public class LessonsLearntManager : DatabaseTable<LessonsLearntManager, LessonsLearnt>{//Manager specific code}


and can be used as such:

MyGridView.DataSource = LessonsLearntManager.Instance.List;


which is a far bit better than previously (the class declaration anyway, the usage doesn't change much).

• Based on the naming guidelines variables should be named using camelCase casing, at least if you don't have any internal naming guidelines.
So Lazy should become lazy or much better lazyManager to make it clear what's the lazy is about.
What I would like to suggest is to rename the class to better reflect its usage and makes it clear from the name what it is about. Maybe DatatableManager would be better.
• I've seen static readonly variables used as a stand in for const quite often these days, and it seems to be convention to name them using PascalCase as if they were consts. – Nick Udell Jul 6 '15 at 9:31
• I would agree if this variable would be public. For a private variable I prefer camelCase casing. – Heslacher Jul 6 '15 at 9:35