date:20111026

Re: Other developers don't like dependency injection

2011-10-26 Thread mike smith

On Thu, Oct 27, 2011 at 3:00 PM, Nathan Schultz  wrote:

> I'd probably sell it differently.
>
> Instead of saying you "don't know" where the objects come from, say that
> objects come from a centrally configured location (since in practice the
> objects are usually defined in configuration, or in bootstrap code).
>
> And sell cheaper maintenance costs (modular design, easy to refactor, easy
> to replace components, easier to extend, fewer system wide bugs, helps with
> a cleaner implementation, less spaghetti code, etc).
>
> To get it past some of the "old hats" here I temporarily changed
> terminology. Dependency Injection (let alone IoC) would draw blank looks,
> but say "plug-in system", and they've all rolled one before and are
> comfortable with the concept.
>
>
>
Also, it sounds like those baddies, DLL Injection & SQL Injection.  Make it
sound different, and you could get a better reaction.


-- 
Meski

 http://courteous.ly/aAOZcv

"Going to Starbucks for coffee is like going to prison for sex. Sure, you'll
get it, but it's going to be rough" - Adam Hills

Re: Other developers don't like dependency injection

2011-10-26 Thread Scott Barnes

heh, in all the years I've seen DI (dating back to a Spring like world with
beans via XML) i often see this type of argument spring up (hah, i worked
that in beautifully). To me there is but one and only one reason you adopt
DI.

"I'm freaking lazy"

There is no separation really as either you take a "HAS-A" dependency
upfront or you get it done later via a construct / method pass-in but either
way you couple up to the interface at the very least (if not
the concrete class itself).

It still comes back to the whole "man, if only i had enough time to plan
this through...i'd sure like it if i could have an IFoo class ri...oh it
is...thank you Autofac..*kiss*..."

:)



---
Regards,
Scott Barnes
http://www.riagenic.com


On Thu, Oct 27, 2011 at 2:07 PM,  wrote:

> **
>
> Not wanting to start a flame war here, but DI has some dissenters:
>
> Black hat on :
>
> How can you say that dependency injection (I’m not taking on the whole
> inversion of control pattern, but I might. Jury’s still out on that one.)
> creates loosely coupled units that can be reused easily when the whole point
> of DI is to require the caller to provide the callee’s needs? That’s an
> increase in coupling by any reasonable assessment. Dumping the coupling
> workload onto a framework doesn’t change the fact that it’s still a
> requirement to supply external stuff to use an object.
>
> When you use DI as a ’Silver Bullet’ you are losing more then half the
> abilities of your programming language. You can not use static methods or
> the ‘new‘ keyword or sealed types. Oh, you have to make all your methods
> virtual too.
>
> Black hat off.
>
> I use DI quite a lot, and it has a number of benefits but it is not a
> magical solution.
>
>
>
> Rob
>
> On Thu, 27 Oct 2011 12:00:26 +0800, Nathan Schultz wrote:
>
> I'd probably sell it differently.
>
> Instead of saying you "don't know" where the objects come from, say that
> objects come from a centrally configured location (since in practice the
> objects are usually defined in configuration, or in bootstrap code).
>
> And sell cheaper maintenance costs (modular design, easy to refactor, easy
> to replace components, easier to extend, fewer system wide bugs, helps with
> a cleaner implementation, less spaghetti code, etc).
>
> To get it past some of the "old hats" here I temporarily changed
> terminology. Dependency Injection (let alone IoC) would draw blank looks,
> but say "plug-in system", and they've all rolled one before and are
> comfortable with the concept.
>
>
>
> On Thu, Oct 27, 2011 at 11:56 AM, Stephen Price 
> wrote:
>
>> Try not to think of it as right and wrong. Alt.net is a guide. It can
>> help you find the path.
>>
>> On Thu, Oct 27, 2011 at 11:15 AM, Michael Ridland 
>> wrote:
>> >
>> > So I've been working with this client for a few years now, all the other
>> > developers aren't alt.net type. They're older and just love their RAD,
>> User
>> > Controls, coming from a dephi background.
>> > It took me a while but finally I got them doing unit testing, but still
>> not
>> > as much as I would like.
>> > Today I also tried to convince them(the development manager) to
>> > use dependency injection but he said it was over complicating things and
>> > it's confusing because you didn't know where the object came from. I
>> argued
>> > for decoupling and that objects shouldn't need to know
>> > where dependences came from or how they were instantiated, objects
>> should
>> > only worry about their unit of work.
>> > Am I wrong?
>> >
>>
>
>

Re: Other developers don't like dependency injection

2011-10-26 Thread Michael Minutillo

If you are using a good DI solution then the caller also has it's
dependencies injected. If it needs an X to pass to the callee then it will
have one injected (or it will have the means to create one injected
[abstract factories are a good example]). If you extrapolate that out you
end up with all of the decisions about *how to structure* your application
in a layer by itself. This layer tends to be easier to implement using an
IoC container but it doesn't need to be, you can roll it by hand if
necessary.

That means that instead of "not knowing where the objects come from" you
actually should only have one place to look.

Note that the "loosely coupled units of work that can be reused easily" only
occurs when all of your classes dependencies are abstractions. When your
dependencies are abstractions the implementation of the actual (concrete)
object you are talking to can vary independent of your class's
implementation as long as the class you depend on adheres to the
abstraction. This means you can reuse ANY of your classes in different
contexts by reimplementing those abstractions that need to change for the
new context. This context might be a test harness or it might be another
part of your application or it might be another project entirely that
requires the same business logic/algorithm.

Having said all of that I know that selling it to a team that is not
interested can be hard. If your app has any contact with any external
systems (and they nearly all do) I'd introduce DI at those locations and use
the excuse "it allows us to test OUR application without testing that
external system" and then start to work your way back into the core. Start
with "poor mans dependency injection" by

For a given class:
1. Write/find abstractions for each of your dependencies
2. Change all variables that point to references of concrete dependencies in
your class to use the abstractions
3. Shift the construction logic for those dependencies into the default
constructor (this where you might need Func<> [which is an abstraction] to
help you create factories or actually roll factory classes)
4. Create a 2nd constructor that accepts all of your abstract dependencies
as parameters and use it for testing

This prepares the class for DI in the future but isolates the change so that
the rest of the app does not need to be modified. As each class that depends
on this class is updated, use the constructor created in step 4 instead of
the one in step 3. Eventually you will be able to delete the step 3
constructor.

I feel I am rambling now so I'll leave it there :)

Michael M. Minutillo
Indiscriminate Information Sponge
http://codermike.com

On Thu, Oct 27, 2011 at 12:07 PM,  wrote:

> **
>
> Not wanting to start a flame war here, but DI has some dissenters:
>
> Black hat on :
>
> How can you say that dependency injection (I’m not taking on the whole
> inversion of control pattern, but I might. Jury’s still out on that one.)
> creates loosely coupled units that can be reused easily when the whole point
> of DI is to require the caller to provide the callee’s needs? That’s an
> increase in coupling by any reasonable assessment. Dumping the coupling
> workload onto a framework doesn’t change the fact that it’s still a
> requirement to supply external stuff to use an object.
>
> When you use DI as a ’Silver Bullet’ you are losing more then half the
> abilities of your programming language. You can not use static methods or
> the ‘new‘ keyword or sealed types. Oh, you have to make all your methods
> virtual too.
>
> Black hat off.
>
> I use DI quite a lot, and it has a number of benefits but it is not a
> magical solution.
>
>
>
> Rob
>
> On Thu, 27 Oct 2011 12:00:26 +0800, Nathan Schultz wrote:
>
> I'd probably sell it differently.
>
> Instead of saying you "don't know" where the objects come from, say that
> objects come from a centrally configured location (since in practice the
> objects are usually defined in configuration, or in bootstrap code).
>
> And sell cheaper maintenance costs (modular design, easy to refactor, easy
> to replace components, easier to extend, fewer system wide bugs, helps with
> a cleaner implementation, less spaghetti code, etc).
>
> To get it past some of the "old hats" here I temporarily changed
> terminology. Dependency Injection (let alone IoC) would draw blank looks,
> but say "plug-in system", and they've all rolled one before and are
> comfortable with the concept.
>
>
>
> On Thu, Oct 27, 2011 at 11:56 AM, Stephen Price 
> wrote:
>
>> Try not to think of it as right and wrong. Alt.net is a guide. It can
>> help you find the path.
>>
>> On Thu, Oct 27, 2011 at 11:15 AM, Michael Ridland 
>> wrote:
>> >
>> > So I've been working with this client for a few years now, all the other
>> > developers aren't alt.net type. They're older and just love their RAD,
>> User
>> > Controls, coming from a dephi background.
>> > It took me a while but finally I got them doing unit testing, but still
>> not
>> > as

Re: Other developers don't like dependency injection

2011-10-26 Thread randrew

Not wanting to start a flame war here, but DI has some dissenters:

Black hat on : 

How can you say that dependency injection (I'm not
taking on the whole inversion of control pattern, but I might. Jury's
still out on that one.) creates loosely coupled units that can be reused
easily when the whole point of DI is to require the caller to provide
the callee's needs? That's an increase in coupling by any reasonable
assessment. Dumping the coupling workload onto a framework doesn't
change the fact that it's still a requirement to supply external stuff
to use an object. 

When you use DI as a 'Silver Bullet' you are losing
more then half the abilities of your programming language. You can not
use static methods or the 'new' keyword or sealed types. Oh, you have to
make all your methods virtual too. 

Black hat off. 

I use DI quite a
lot, and it has a number of benefits but it is not a magical solution.

Rob 

On Thu, 27 Oct 2011 12:00:26 +0800, Nathan Schultz wrote: 

>
I'd probably sell it differently.
> 
> Instead of saying you "don't
know" where the objects come from, say that objects come from a
centrally configured location (since in practice the objects are usually
defined in configuration, or in bootstrap code). 
> 
> And sell cheaper
maintenance costs (modular design, easy to refactor, easy to replace
components, easier to extend, fewer system wide bugs, helps with a
cleaner implementation, less spaghetti code, etc).
> 
> To get it past
some of the "old hats" here I temporarily changed terminology.
Dependency Injection (let alone IoC) would draw blank looks, but say
"plug-in system", and they've all rolled one before and are comfortable
with the concept.
> 
> On Thu, Oct 27, 2011 at 11:56 AM, Stephen Price
wrote:
> 
>> Try not to think of it as right and wrong. Alt.net is a
guide. It can
>> help you find the path.
>> 
>> On Thu, Oct 27, 2011 at
11:15 AM, Michael Ridland wrote:
>> >
>> > So I've been working with
this client for a few years now, all the other
>> > developers aren't
alt.net [2] type. They're older and just love their RAD, User
>> >
Controls, coming from a dephi background.
>> > It took me a while but
finally I got them doing unit testing, but still not
>> > as much as I
would like.
>> > Today I also tried to convince them(the development
manager) to
>> > use dependency injection but he said it was over
complicating things and
>> > it's confusing because you didn't know
where the object came from. I argued
>> > for decoupling and that
objects shouldn't need to know
>> > where dependences came from or how
they were instantiated, objects should
>> > only worry about their unit
of work.
>> > Am I wrong?
>> >

Links:
--
[1]
mailto:rid...@gmail.com
[2] http://alt.net
[3]
mailto:step...@littlevoices.com

Re: Other developers don't like dependency injection

2011-10-26 Thread Nathan Schultz

I'd probably sell it differently.

Instead of saying you "don't know" where the objects come from, say that
objects come from a centrally configured location (since in practice the
objects are usually defined in configuration, or in bootstrap code).

And sell cheaper maintenance costs (modular design, easy to refactor, easy
to replace components, easier to extend, fewer system wide bugs, helps with
a cleaner implementation, less spaghetti code, etc).

To get it past some of the "old hats" here I temporarily changed
terminology. Dependency Injection (let alone IoC) would draw blank looks,
but say "plug-in system", and they've all rolled one before and are
comfortable with the concept.

On Thu, Oct 27, 2011 at 11:56 AM, Stephen Price wrote:

> Try not to think of it as right and wrong. Alt.net is a guide. It can
> help you find the path.
>
> On Thu, Oct 27, 2011 at 11:15 AM, Michael Ridland 
> wrote:
> >
> > So I've been working with this client for a few years now, all the other
> > developers aren't alt.net type. They're older and just love their RAD,
> User
> > Controls, coming from a dephi background.
> > It took me a while but finally I got them doing unit testing, but still
> not
> > as much as I would like.
> > Today I also tried to convince them(the development manager) to
> > use dependency injection but he said it was over complicating things and
> > it's confusing because you didn't know where the object came from. I
> argued
> > for decoupling and that objects shouldn't need to know
> > where dependences came from or how they were instantiated, objects should
> > only worry about their unit of work.
> > Am I wrong?
> >
>

Re: Other developers don't like dependency injection

2011-10-26 Thread Stephen Price

Try not to think of it as right and wrong. Alt.net is a guide. It can
help you find the path.

On Thu, Oct 27, 2011 at 11:15 AM, Michael Ridland  wrote:
>
> So I've been working with this client for a few years now, all the other
> developers aren't alt.net type. They're older and just love their RAD, User
> Controls, coming from a dephi background.
> It took me a while but finally I got them doing unit testing, but still not
> as much as I would like.
> Today I also tried to convince them(the development manager) to
> use dependency injection but he said it was over complicating things and
> it's confusing because you didn't know where the object came from. I argued
> for decoupling and that objects shouldn't need to know
> where dependences came from or how they were instantiated, objects should
> only worry about their unit of work.
> Am I wrong?
>

RE: Other developers don't like dependency injection

2011-10-26 Thread James Chapman-Smith

No, you are not wrong.

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Michael Ridland
Sent: Thursday, 27 October 2011 13:46
To: ozDotNet
Subject: Other developers don't like dependency injection

So I've been working with this client for a few years now, all the other 
developers aren't alt.net type. They're older and just love 
their RAD, User Controls, coming from a dephi background.

It took me a while but finally I got them doing unit testing, but still not as 
much as I would like.

Today I also tried to convince them(the development manager) to use dependency 
injection but he said it was over complicating things and it's confusing 
because you didn't know where the object came from. I argued for decoupling and 
that objects shouldn't need to know where dependences came from or how they 
were instantiated, objects should only worry about their unit of work.

Am I wrong?

Other developers don't like dependency injection

2011-10-26 Thread Michael Ridland

So I've been working with this client for a few years now, all the other
developers aren't alt.net type. They're older and just love their RAD, User
Controls, coming from a dephi background.

It took me a while but finally I got them doing unit testing, but still not
as much as I would like.

Today I also tried to convince them(the development manager) to
use dependency injection but he said it was over complicating things and
it's confusing because you didn't know where the object came from. I argued
for decoupling and that objects shouldn't need to know
where dependences came from or how they were instantiated, objects should
only worry about their unit of work.

Am I wrong?

Sharepoint 2010 - Is it safe to delete doc library templates?

2011-10-26 Thread Winston Pang

Hey everyone,


Quick question, if you have a doc library template, and you've created some
doc library instances based off this template, is it safe to remove this
template once you're done with it?

Thanks.

-Winston

RE: while (true) using Parallel.ForEach

2011-10-26 Thread James Chapman-Smith

Hi Tom,

I've got some examples, but why do you want to do this?

   // Something to do in the loop
   Action action =
  () => Console.WriteLine(Thread.CurrentThread.ManagedThreadId);

   // standard while(true) loop
   while (true)
   {
  action();
   }

   // Now need an infinite enumerable
   private IEnumerable Forever()
   {
  return Repeat(true);
   }

   // a general purpose infinite enumerable
   private IEnumerable Repeat(T value)
   {
  while (true)
  {
 yield return value;
  }
   }

   // ForEach infinite loop
   Parallel.ForEach(Forever(), b => action());
   Parallel.ForEach(Repeat(true), b => action());

   // AsParallel/ForAll infinite loop
   Forever().AsParallel().ForAll(b => action());
   Repeat(true).AsParallel().ForAll(b => action());

   // Using Interactive Extensions (Ix) Repeat extension method
   // from the Reactive Extensions (Rx) Team
   // so you don't have to roll your own
   Parallel.ForEach(EnumerableEx.Repeat(true), b => action());
   EnumerableEx.Repeat(true).AsParallel().ForAll(b => action());

Is this what you wanted?

Cheers.

James.

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Tom Gao
Sent: Wednesday, 26 October 2011 23:57
To: 'ozDotNet'
Subject: while (true) using Parallel.ForEach

Hi All,

Can someone please provide me with an example of how I can replicate a 
while(true){ ... } using Parallel.ForEach?

Thank you,
Tom

RE: Setting DOS environment variables

2011-10-26 Thread David Kean

It's a collection, you add to it:
startInfo.EnvironmentVariables.Add("TEMP", "C:\Temp")

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Ian Thomas
Sent: Wednesday, October 26, 2011 2:32 AM
To: 'ozDotNet'
Subject: RE: Setting DOS environment variables

Get, no Set

Ian Thomas
Victoria Park, Western Australia

From: ozdotnet-boun...@ozdotnet.com 
[mailto:ozdotnet-boun...@ozdotnet.com]
 On Behalf Of David Kean
Sent: Wednesday, October 26, 2011 8:24 AM
To: ozDotNet
Subject: RE: Setting DOS environment variables

Have you tried ProcessStartInfo.EnvironmentVariables?

http://msdn.microsoft.com/en-us/library/system.diagnostics.processstartinfo.environmentvariables.aspx

From: ozdotnet-boun...@ozdotnet.com 
[mailto:ozdotnet-boun...@ozdotnet.com]
 On Behalf Of Greg Keogh
Sent: Saturday, October 22, 2011 6:49 PM
To: 'ozDotNet'
Subject: Setting DOS environment variables

Several years ago I tried to find a way of setting (creating) DOS environment 
variables in code and then using the values in batch files. I remember I failed 
because the variables only existed for the duration of the process. I had a 
fresh look at this problem today and was thrilled to see a 3rd argument added 
to the 
SetEnvironmentVariable
 method. I wrote a console app with this single line of code:

Environment.SetEnvironmentVariable("Foo", string.Format("{0:HHmmss}", 
DateTime.Now), EnvironmentVariableTarget.User);

In a bat file I then called this app followed by a "set f" command. But sadly 
the Foo value is not present. I tried setting target to Machine, but this 
requires admin privileges to write to HKLM. Even more sadly it does work either 
because it seems to write the reg entry but the new value is not immediately 
picked up by the batch file.

Does anyone know of a trick to programmatically set environment variables for 
use in a bat file?

Greg

Re: while (true) using Parallel.ForEach

2011-10-26 Thread Grant Molloy

Hi Tom,
Check out Sacha Barber's TPL posts on code project.

Grant
On 26/10/2011 11:27 PM, "Tom Gao"  wrote:

> Hi All,
>
> ** **
>
> Can someone please provide me with an example of how I can replicate a
> while(true){ … } using Parallel.ForEach?
>
> ** **
>
> Thank you,
>
> Tom
>
> ** **
>

while (true) using Parallel.ForEach

2011-10-26 Thread Tom Gao

Hi All,

 

Can someone please provide me with an example of how I can replicate a
while(true){ . } using Parallel.ForEach?

 

Thank you,

Tom

RE: Setting DOS environment variables

2011-10-26 Thread Ian Thomas

Get, no Set 

 

  _  

Ian Thomas
Victoria Park, Western Australia

  _  

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of David Kean
Sent: Wednesday, October 26, 2011 8:24 AM
To: ozDotNet
Subject: RE: Setting DOS environment variables

 

Have you tried ProcessStartInfo.EnvironmentVariables?

 

http://msdn.microsoft.com/en-us/library/system.diagnostics.processstartinfo.
environmentvariables.aspx

 

 

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Greg Keogh
Sent: Saturday, October 22, 2011 6:49 PM
To: 'ozDotNet'
Subject: Setting DOS environment variables

 

Several years ago I tried to find a way of setting (creating) DOS
environment variables in code and then using the values in batch files. I
remember I failed because the variables only existed for the duration of the
process. I had a fresh look at this problem today and was thrilled to see a
3rd argument added to the SetEnvironmentVariable
  method. I wrote a console app with this single line of code:

 

Environment.SetEnvironmentVariable("Foo", string.Format("{0:HHmmss}",
DateTime.Now), EnvironmentVariableTarget.User);

 

In a bat file I then called this app followed by a "set f" command. But
sadly the Foo value is not present. I tried setting target to Machine, but
this requires admin privileges to write to HKLM. Even more sadly it does
work either because it seems to write the reg entry but the new value is not
immediately picked up by the batch file.

 

Does anyone know of a trick to programmatically set environment variables
for use in a bat file?

 

Greg

Re: Other developers don't like dependency injection

Re: Other developers don't like dependency injection

Re: Other developers don't like dependency injection

Re: Other developers don't like dependency injection

Re: Other developers don't like dependency injection

Re: Other developers don't like dependency injection

RE: Other developers don't like dependency injection

Other developers don't like dependency injection

Sharepoint 2010 - Is it safe to delete doc library templates?

RE: while (true) using Parallel.ForEach

RE: Setting DOS environment variables

Re: while (true) using Parallel.ForEach

while (true) using Parallel.ForEach

RE: Setting DOS environment variables

14 matches

Site Navigation

Mail list logo

Footer information