Is decoupling the ultimate goal?
-
We all know that we should program against interfaces not implementations, because when we decouple that we get a lot more manageable code. There is no question about that. I think almost all IoC-frameworks (Castle Windsor, Ninject, etc.) are able to scan assemblies for interface implementations and instantiate those classes at run-time. That means that we do not even need a reference to the assembly which is implementing the needed functionality. Cool, a lot of decoupling is going on... But that means, that we have to copy all the needed assemblies manually somehow. VS can't do this for us any longer. Same with the VS-Setup project. It isn't able to detect the necessary assemblies any more. Is that a goal? It feels to me like this makes life harder as it needs to be... What do you think?
-
We all know that we should program against interfaces not implementations, because when we decouple that we get a lot more manageable code. There is no question about that. I think almost all IoC-frameworks (Castle Windsor, Ninject, etc.) are able to scan assemblies for interface implementations and instantiate those classes at run-time. That means that we do not even need a reference to the assembly which is implementing the needed functionality. Cool, a lot of decoupling is going on... But that means, that we have to copy all the needed assemblies manually somehow. VS can't do this for us any longer. Same with the VS-Setup project. It isn't able to detect the necessary assemblies any more. Is that a goal? It feels to me like this makes life harder as it needs to be... What do you think?
That's what I tell my wife, but she just doesn't see it that way.
-
We all know that we should program against interfaces not implementations, because when we decouple that we get a lot more manageable code. There is no question about that. I think almost all IoC-frameworks (Castle Windsor, Ninject, etc.) are able to scan assemblies for interface implementations and instantiate those classes at run-time. That means that we do not even need a reference to the assembly which is implementing the needed functionality. Cool, a lot of decoupling is going on... But that means, that we have to copy all the needed assemblies manually somehow. VS can't do this for us any longer. Same with the VS-Setup project. It isn't able to detect the necessary assemblies any more. Is that a goal? It feels to me like this makes life harder as it needs to be... What do you think?
Is there a problem in adding a reference to the dependent assemblies?
Quote:
Same with the VS-Setup project. It isn't able to detect the necessary assemblies any more.
For sure, VS Setup project will not have an idea about the DI Container or has knowledge about the interfaces and it's concert implementation. Thanks,
Ranjan.D
-
We all know that we should program against interfaces not implementations, because when we decouple that we get a lot more manageable code. There is no question about that. I think almost all IoC-frameworks (Castle Windsor, Ninject, etc.) are able to scan assemblies for interface implementations and instantiate those classes at run-time. That means that we do not even need a reference to the assembly which is implementing the needed functionality. Cool, a lot of decoupling is going on... But that means, that we have to copy all the needed assemblies manually somehow. VS can't do this for us any longer. Same with the VS-Setup project. It isn't able to detect the necessary assemblies any more. Is that a goal? It feels to me like this makes life harder as it needs to be... What do you think?
The goal is to have a working application that is even easier to write / maintain / debug than last one. Over engineering is a pain in the neck! It's a balance you have to strike. You can now it's is over engineered after a little bit of use, if all the "framework" in place feels like pointless drudgework going in the way of simpler implementation then something is wrong. In my previous job in a web shop, I did meet an overengineering PM. Boy what a pain. And that created lots of bug and slow down too. On the other hand I wrote my own 2 all in one IoC, DiY, which I use everywhere and they make my life so much easier! :) Evidently I am biased towards it.. But I found an easy way to check the value of something is to put it, explain it to your coworker and let them adopt it (or not) anyway they see fit. Adoption will be a measure of fitness and value! ;)
All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
-
We all know that we should program against interfaces not implementations, because when we decouple that we get a lot more manageable code. There is no question about that. I think almost all IoC-frameworks (Castle Windsor, Ninject, etc.) are able to scan assemblies for interface implementations and instantiate those classes at run-time. That means that we do not even need a reference to the assembly which is implementing the needed functionality. Cool, a lot of decoupling is going on... But that means, that we have to copy all the needed assemblies manually somehow. VS can't do this for us any longer. Same with the VS-Setup project. It isn't able to detect the necessary assemblies any more. Is that a goal? It feels to me like this makes life harder as it needs to be... What do you think?
Bear in mind that interfaces were only introduced because so many people either couldn't or wouldn't use common sense and code robustly. It was one solution, and it was easy for people to get their heads around, so it was adopted as a standard. If you have a robust solution that doesn't decouple in quite the same way, go ahead and try it out.
I wanna be a eunuchs developer! Pass me a bread knife!
-
That's what I tell my wife, but she just doesn't see it that way.
And in this case a decoupled solution would make life easier :-)
-
We all know that we should program against interfaces not implementations, because when we decouple that we get a lot more manageable code. There is no question about that. I think almost all IoC-frameworks (Castle Windsor, Ninject, etc.) are able to scan assemblies for interface implementations and instantiate those classes at run-time. That means that we do not even need a reference to the assembly which is implementing the needed functionality. Cool, a lot of decoupling is going on... But that means, that we have to copy all the needed assemblies manually somehow. VS can't do this for us any longer. Same with the VS-Setup project. It isn't able to detect the necessary assemblies any more. Is that a goal? It feels to me like this makes life harder as it needs to be... What do you think?
I personally would NOT get carried away with all the decoupling crap and over engineering (as others have mentioned). Sounds to me that you are questioning this mantra that engineers have been touting as of late. I have worked on systems that became so complex due to all this unnecessary B.S. that developers were doing in the name of "proper software design" that it became completely, and utterly unmanageable, which is what the were "trying" to avoid in the first place.
Sven Bardos wrote:
Is that a goal?
No, that is not the goal. It was never intended to be the goal.
Sven Bardos wrote:
It feels to me like this makes life harder as it needs to be...
Very true and it is only getting worse from what I can tell.
-
We all know that we should program against interfaces not implementations, because when we decouple that we get a lot more manageable code. There is no question about that. I think almost all IoC-frameworks (Castle Windsor, Ninject, etc.) are able to scan assemblies for interface implementations and instantiate those classes at run-time. That means that we do not even need a reference to the assembly which is implementing the needed functionality. Cool, a lot of decoupling is going on... But that means, that we have to copy all the needed assemblies manually somehow. VS can't do this for us any longer. Same with the VS-Setup project. It isn't able to detect the necessary assemblies any more. Is that a goal? It feels to me like this makes life harder as it needs to be... What do you think?
My take on this sort of thing is that it's possible to become obsessed with a particular framework and insist on using it, becoming an "evangelist" for this sacred new framework. On the other hand, it's possible to become obsessed with getting something out as quickly as possible with code hacked together from the recesses of Google. Neither of these extreme approaches is a good idea - if a framework helps then use it while being aware of its limitations and allowing yourself some slack as you probably have a deadline to meet. On the other hand writing poorly thought out code is going to cause you a headache and worse in a few month's time. I don't think there is a clear boundary of where the emphasis should go as you don't have infinite time, in which to write the perfect code, nor do you have omniscience with which to see every possibility that may not be covered by your code(even code that gets into aircraft is buggy!). If you can't look back on code that is a year old and think "I would probably not do things that way nowadays" - you are probably not learning from your experience.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
We all know that we should program against interfaces not implementations, because when we decouple that we get a lot more manageable code. There is no question about that. I think almost all IoC-frameworks (Castle Windsor, Ninject, etc.) are able to scan assemblies for interface implementations and instantiate those classes at run-time. That means that we do not even need a reference to the assembly which is implementing the needed functionality. Cool, a lot of decoupling is going on... But that means, that we have to copy all the needed assemblies manually somehow. VS can't do this for us any longer. Same with the VS-Setup project. It isn't able to detect the necessary assemblies any more. Is that a goal? It feels to me like this makes life harder as it needs to be... What do you think?
Thanks all for sharing your opinion! I will try to stay away from this kind of decoupling!