C# Static Method vs Object Instance

Question

I'm currently developing a C# MVC REST web api, and am trying to choose between one of two possibilities for our design.

Without getting too deep into our design, we intend to have a class for data access, which we'll call DataSource. Each DataSource will need to execute small, contained blocks of logic to correctly build an appropriate response. Due to a desire to be able to hot-load code in the future, we don't want to simply have these be functions on DataSource, instead we'd like them to be provided by other assemblies. We have a proof of concept of this implemented, and so far, so good.

What I'm trying to decide between is writing a static class with a single static ExecuteQuery function, or writing a factory method to create instances of these classes, which have an instance method called ExecuteQuery.

What are the performance considerations between creating multiple, short-lived objects every request, vs calling static methods?

Intuitively, static methods would be faster, but I'm already expecting that I'll run into a bit of a headache calling them through reflection (to support the hot-loaded code requirement).

If there's not a huge penalty for short-lived objects, then they might win out on simplicity alone.

Relevant information about our expect loads:

• Response times in the 300ms - 800ms range
• Average load of about 2000 web clients
• Peak load of about 4000 clients
• Clients doing queries every 2 - 5 seconds
• Client peak rate of 1 query every second

Also, each DataSource would create a maximum of 8, average of 3 of these instances.

Answer 1

Use a static class, that delegates the calls to the implementation classes.

These implementation classes should implement a common interface, which will allow you to call methods on them without needing reflection. And of course, static methods can't implement interface methods. Interface implementations have to be instances, you need some kind of factory to instantiate them. If they live in external assemblies, I strongly suggest you take a look at the Managed Extensibility Framework (MEF), see http://msdn.microsoft.com/en-us/library/dd460648.aspx.

What are the performance considerations between creating multiple, short-lived objects every request, vs calling static methods? Given that these methods will do data access, the performance implications are totally completely and utterly negligable.

If you use MEF, the framework will create singleton-like instances for you.

If you role your own, and want to remove the need to create these objects multiple times, you can implement the Singleton pattern on them.

Answer 2

I assume each DataSource instance will make a new connection to the database. If so, then it would make sense to only have one instance. The only way to find out if "it's a huge penalty" is to create a mock-up of both solutions and profile and see if the impact is significant or not.

• Since you do not seem to have many clients at once, so this also sits will with the Singleton pattern.
• Not many concurrent queries(mostly because of above statement).
• You have a Defined specification of response time.

The only argument I can make for the Factory pattern is for "simplicity". If the project is truly time sensitive, then I guess you have no choice. But if you really want performance, go with Singleton.