5

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.

Chris Case
  • 236
  • 5
  • 9
  • Probably your intent to use reflection will cause a larger performance hit than static-vs-instance usage. As others have commented, you should choose the form that makes the most _design_ sense. Alternatively, since you have some intended metrics, you could mock a static/instance implementation and get a sense of the overhead you'll face. – Chris Sinclair May 26 '12 at 02:40

4 Answers4

1

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.

stan
  • 4,885
  • 5
  • 49
  • 72
1

Use MEF. No need to invent your own plugin framework. It will steer you towards instance methods exposed via interfaces. It is not uncommon to create per-request objects... the MVC framework does that all over the place. Per-request instances are a particularly good thing for data access scenarios so that you can support things like transactions/rollbacks in a way where one user's experience doesn't impact other users until you explicitly make it. Use response caching where appropriate if perf is a problem.

Robert Levy
  • 28,747
  • 6
  • 62
  • 94
  • That's a very good point, it hadn't occurred to me that MVC has to be making multiple objects on a per request basis. I will definitely look into MEF, as it's now been mentioned twice, and at a cursory glance, it looks like exactly what I want. – Chris Case May 26 '12 at 02:47
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.

Kris Vandermotten
  • 10,111
  • 38
  • 49
  • I had debated using the Singleton patter on them, but hadn't made any decisions yet. I think MEF will be exactly what I'm looking for. Thanks! – Chris Case May 26 '12 at 02:45
0

The main decision should be "does this object have state?"

If "No", then by all means, make it a static method.

IMHO .. PSM

paulsm4
  • 114,292
  • 17
  • 138
  • 190
  • Unfortunately, the requirements for all of the possible objects aren't in yet, so while I don't think they'll have state, I can't be 100% certain at this stage. – Chris Case May 26 '12 at 02:48