@bondsbw: Like portability, multi-developer conflicts are not an issue I've ever had a problem with (there are only 6 developers in my company, but we often all work on the same project at the same time).  We've never had an instance of a developer removing a class from IoC without checking first that the interface is not used anywhere else -- that would be poor developer practice in my book, regardless of IoC technique.

 

@Charles: I keep hearing people saying this kind of thing, but in my context this is not a major concern -- I'm writing LOB applications for a vertical market who will buy the hardware to suit the software, so portability is not an issue.

For example, we are coded against SQL Server so that is what our customers buy to run our system. If MS were to kill off SQL Server, we would be stuffed because we use hand-coded and optimised stored procedures a lot for complex data-crunching. If we were to make that code portable to any database system we would lose the specific SQL Server optimisations and we would have a slow, unusable system.

As long as WinForms is around, we don't have to change anything.  When we have to move to a new UI technology we just need to rewrite the UI elements using the same controllers; IoC and decoupling doesn't make a major impact on this as it's a 1 to 1 match between UI and controller.  If C# and .NET were to die, then no amount of portability will help.

I think I'm on a down-swing with architecture -- yes it's important to have a deep understanding of all the principals and techniques, but it's also important to understand when they are overkill and would just waste time and add complexity for no or little real benefit. I guess it's architectural YAGNI.

 

Herbie