|
|
There have in the past been some people who sit in the car facing my house. Parke on the street for no obvious reason.
I have 15x 70mm binoculars. They are big.
Me standing on the porch, looking back through it. They drive away 
|
|
|
|
|
Get a telescope and you'll see half of it.
|
|
|
|
|
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.
|
|
|
|
|
And in this case a decoupled solution would make life easier 
|
|
|
|
|
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
|
|
|
|
|
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! 
|
|
|
|
|
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!
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
Thanks all for sharing your opinion! I will try to stay away from this kind of decoupling!
|
|
|
|
|
| 1.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
1. I usually...oh look, shiny!
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Initiative comes to thems that wait.
- Alex
|
|
|
|
|
- CodeProject
- CodeProject
- CodeProject
- CodeProject
- CodeProject
- CodeProject
- CodeProject
- CodeProject
- CodeProject
- Girlfriend
|
|
|
|
|
Whose girlfriend doesn't read CP?
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: Whose girlfriend doesn't read CP?
Even if she did, she'd laugh and probably agree!
Marc
|
|
|
|
|
She sounds like a real gem. Lucky you
|
|
|
|
|
0.Girlfriend
1.CodeProject
2.CodeProject
3.CodeProject
4.CodeProject
5.CodeProject
6.CodeProject
7.CodeProject
8.CodeProject
9.CodeProject
FTFY
Words to the wise: Always ensure that your girlfriend comes first. 
|
|
|
|
|
[Space reserved for later response]
|
|
|
|
|
SO WRONG! Try this one:
Reason #0.
|
|
|
|
|
1. Should this list be zero based? Well on the one hand it is a technology site but on the other hand it is mainly for a human audience.
10. Wait - doesn't that preclude doing a "10 types of people in the world, those that understand binary.." derivative joke? On the plus side, if it doesn't then my list is complete.
11. Not specifying if the list is zero based or not makes an "off by one" error more likely.
|
|
|
|
|
Procrastination -- there's a nap for that.
|
|
|
|
|
Either do, or do not, because you won't get around to it tomorrow. - Yoda
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
