Reputation: 236
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:
Also, each DataSource
would create a maximum of 8, average of 3 of these instances.
Upvotes: 5
Views: 2140
Reputation: 10201
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.
Upvotes: 1
Reputation: 29073
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.
Upvotes: 1
Reputation: 4995
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.
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.
Upvotes: 1
Reputation: 121689
The main decision should be "does this object have state?"
If "No", then by all means, make it a static method.
IMHO .. PSM
Upvotes: 0