Dependency injection causing poor performance (ASP.NET MVC)

Question

I am not very experienced with dependency injection so I very much value your opinion on the following.

It (dependency injection/IOC) was used in a web application at my company.

The current programming lead at our company hates this app, as he dislikes linq, entity framework and dependency injection (all which feature in the app). He thinks that collectively they all contribute to make the app slow and fragile.

He blames the IOC container most off all for the perceived poor performance and today said words to this effect "I'm not sure, but it (the IOC container) must use reflection, which is very bad".

He also dislikes the use of interfaces (as it makes finding the definition of a file that implements an interface more difficult in Visual Studio) and uses this as another reason to bash IOC containers in general.

I have recently discovered the SOLID principles and the above opinions just do not site right with me so I would like to know what seasoned developers think and if there are any facts to support any of the programming leads opinions.

Thanks for reading.

Answer 1

I've never experienced performance issues caused by dependency injection and I would tend to ignore this.

Separating dependencies between code especially nasties like calls to the database in the front end is a no brainer.

However using LINQ to SQL can definitely cause poorer performance than code in a stored procedure which is managed by SQL Server.

This has to be balanced against the problem of code in your database. SQL is a less powerful language, it's difficult to refactor as you can't call another stored procedure without using dynamic SQL. Also code in your database may not be under source control. I've seen projects suffer badly as there was too much code in the database.

Personally I would use linq to sql but don't be afraid of using a stored procedure for a data intensive operation or poorly performing function.

I'd beware of people who don't like a particular technology but don't back it up with sound arguments. People tend to prefer the technology they have the most experience in.

Answer 2

It's the type of discussion you can't win if you don't change the perspective.

Computers don't mind what kind of code they run. Probably they're even "happier" with code that we would call "spaghetti" because there are less access paths to traverse.

But we don't write code for computers.

All these architectural guidelines like the SOLID principles, all these tools like IoC containers or ORMs, all these 3rd-, 4th-, 5th-generation computer languages were not designed for computers, but for us, software developers.

Simply because the human mind is not a CPU.

So we need all these tools to keep track of what we're designing and to guarantee that what we write can be converted to safe runtime code. Taking it to the extremes, your programming lead shouldn't even allow you the luxury of writing in C# or VB, but force you to write assembler code. Then you'll get unsurpassed performance! (But more likely a shitload of runtime errors).

The right perspective is to talk about maintainable code, because code always evolves. And often there are deadlines. Not the computer, but we should be able to comprehend what we're doing. We separate concerns because we can only comprehend one concern at a time. We use tools to generate SQL because we can't type hundreds of SQL statements without errors, let alone modify them in a reasonable amount of time if the database changes. We use IoC containers because we forget about dependencies or object life cycles.

The balance is really performance vs. maintainable code.

Once this is clear, there is a common ground from which you can do performance measurements. If a tool dramatically increases the time to market at the expense of a slight performance degradation this may be acceptable. Even users will understand that.

---

(I've made this a bit broader than your immediate question, msteel9999's answer is spot-on).