Overarchitected Projects

[SpontaneousOrder]

Now I remember why I left software dev 8 years ago - started struggling with everyone jumping to frameworks and felt it was coding for the sake of coding. I understood the concept of easily reusable code or abstracting from interfaces but never did I actually see code being reused or a whole interface gutted out for a new UI and taking advantage of the abstraction. So why the extra code?!!

Rule of three.

[SpontaneousOrder]

Does it also use dependency injection to add another layer of indirection?

Maybe we're just getting too old for all this crap....

I assume you mean some DI framework, rather than just DI in general?

[DimPrawn]

I assume you mean some DI framework, rather than just DI in general?

Yes, something like Unity for .NET

[SpontaneousOrder]

Yes, something like Unity for .NET

I actually quite like DI frameworks - but buried down below the surface. Inject the factories, and have those factories build nice coarse grained objects with their dependencies hard-coded if you like.

I don't get the obsession with never being seen to be hard-coding any dependency, while hard-coding them in some uber DI config file somewhere.

[jmo21]

I don't get the obsession with never being seen to be hard-coding any dependency, while hard-coding them in some uber DI config file somewhere.

Is so the dependancies can be mocked out and the component can be unit tested in isolation innit?!

[SpontaneousOrder]

Is so the dependancies can be mocked out and the component can be unit tested in isolation innit?!

If 'component' == a class, then yes. But then those tests probably suck.

[BHicks]

The one time I've seen a DI framework (Spring .NET) being used in a production system it was clear it had been massively over-engineered.

The original author probably did it as a bit of CV enhancement and then cleared off. It was being used to implement a custom scheduled reporting solution, but nothing that couldn't have been done with SSRS (Sql Server Reporting Services as they were hitting SQL Server anyway) and an off the shelf scheduling tool.

[suityou01]

These heavily architected projects don't just happen by accident. There is probably a design somewhere. Ask around the enterprise architects for what tools are used for software architecture.

It could of course be that the guy was just using the class modeller in VisualStudio, in which case take a look out for class diagrams in the project itself.

Also these systems tend to be build by "TDD" these days, so there are probably a whole bunch of unit testing projects in the code repo as well. Start with these, and as DP says there might be a DI framework in the mix as well.

Stop thinking in terms of understanding the code, zoom out a little and try and identify some key objects, understand what they do and then start to drill in again and it should become a little clearer. Keep an open mind as this may revolutionise they way you think about software development and you may learn a nifty trick or too along the way. Seriously.

Take a look at Ninject, as this is the best DI framework IMVHO for noobies, and their documentation is friendly and accessible. They don't believe in the XML hell that is other DI frameworks.

[BrilloPad]

4. Try and incorporate the latest technological trends and hot skills in your work, even if they aren't really needed. Learn on the job.

That is the problem. Ba**ard self centered contractors adding in nonsense for the sake of it.

[suityou01]

That is the problem. Ba**ard self centered contractors adding in nonsense for the sake of it.