…on LinkedIn

ASP Ajax vs j-Query for UI development

How to develop an application from scratch using Design Patterns and Best Practices

Interview on MVVM

What would be best way of combining several different data sources for your program?

What’s the best way to persist ‘logged in user’ information?

When to use dependency injection


When to use dependency injection

[ Frank Van Der Geld | ASP.NET MVC Developers ]

I’ve read an discussion about “MVC4 Dependency injection” from aboubacar diaby. It was about which ‘Depencey Injection’ was the best option. I’m more curious about when to use it and when certainly not.

In my experience as a sofware engineer i found two possible usages:

1. To create loosy coupled layers that can easy be altered or replaced. And ofcourse to seperate concerns but that’s more of the same. And this is in a big complex software project as a pre-condition ofcourse. In a small project it’s almost always overkill.

2. To hide most of the logic for example front-end developers to prevent business logic to appear in the front-end or places you don’t want it to appear.

What are your thoughts about this topic?

The new keyword and static objects are “UT’s Hell”.And please stop thinking small. Act local, but think big (and global). Every app, system, process and project is born to grow [with or without us]; and sooner or later one will find him or herself having to comply with some sort of IoC/DI. And, as avoiding rework is one of QA’s tenets, be flexible and KISS! [Keep it simple, stupid!]

Overkill is to reinvent the wheel over and over again and to keep using anti-patterns. Note that many of the IoC/DI codes are open source, so (if you need them over your strict control) you can download it anytime you want. Not to say that they have already been exhaustively tested, proved and approved; since they are widely adopted and very stable, scalable and trustful.

And by the way, IoC/DI also fits perfectly with all fundamental OOP/SOA principles and best practices (besides testability); such as abstraction or hiding implementation details [and that’s all an interface is about]; single responsibility; open for extension and closed for modification; etc.

Summing: IoC/DI is now much more than a trend, a preference, a flavor or an option – it is a must, just like OOP or SOA themselves. It’s not a matter of “if” or “where”: it is a matter of “when”.

The sooner, the better… But that’s just the way I see it.

Capparelli [ apr 2014 ]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: