Dependency injection
Hi, I am using Microsoft unity to do dependency inject but I have a small problem. Let's say I have a business layer assembly and a data layer assembly. The data layer exposes 2 interfaces, IDataRepositortyA and IDataRepositoryB. These are both constructed by unity. Now let's say IDataRepositoryA needs to do some low level calls to repository B, say for some type of mash-up. How do I expose a low level function on repository B that really should not be visible to the business layer. Do I just add the low level functions to the public IDataRepositoryB interface, which makes them visible to the business layer? Or do I create a new interface for the extra low level functions? If I make the new interface internal, how does it work with injection ? Jeff
Dependency Injection
I am experimenting with Dependency Injection in the Microsoft CAB framework.
>From http://blog.irm.se/blogs/home.aspx?App=eric&p=11
Who says
In this post I'm back covering the CreateNew attribute that you can use in a
class that is instantiated by
ObjectBuilder<http://www.codeplex.com/Wiki/View.aspx?ProjectName=ObjectBuilder>.
Marking a property (or parameter to a method or constructor) with the
CreateNew attributes will set that property to an instance of the object. The
instance itself will of course be built by the ObjectBuilder too. A great
example of when to use this functionality is if you want to implement your GUI
with for example the Model View Presenter (MVP) design pattern. I will only
focus on the View and Presenter here.
I have this basic piece of code
private ContentPresenter _contentPresenter;
[CreateNew]
public ContentPresenter Presenter
{
get { return _contentPresenter; }
set { _contentPresenter = value;}
}
The objectBuilder may instantiate the ContentPresenter for me but I suspect it
wil use the the default parameterless constructer (or expect one).
How can I pass a parameter (in this case a reference to my view that implements
the interface that will be used
By my presenter.
I have a solution that does not use Dependency Injection but would like the
advantages of loose coupling if possible.
Has anyone played (sorry used) the ObjectBuilder in the CAB framework for
dependancy injection of this type and if so how can it be used to specify a
constructor with a parameter.
I have looked at the attributes here
http://www.ikriv.com/en/prog/info/dotnet/CabDependencyInjection/DependencyAttributes.html#CreateNew
But that has not helped me much (actually not at all in fact).
I am a sub novice (if one can get that low) with Dependancy Injection.
Regards Peter Maddin
Applications Development Officer
PathWest Laboratory Medicine WA
Phone : +618 9473 3944
Fax : +618 9473 3982
E-Mail : peter.mad...@pathwest.wa.gov.au
The contents of this e-mail transmission outside of the WAGHS network are
intended solely for the named recipient's), may be confidential, and may be
privileged or otherwise protected from disclosure in the public interest. The
use, reproduction, disclosure or distribution of the contents of this e-mail
transmission by any person other than the named recipient(s) is prohibited. If
you are not a named recipient please notify the sender immediately.
RE: Dependency injection
Hi Jeff, You need to think twice about exposing low-level functionality through a high-level interface. The purpose of repositories is, in one respect, to hide low level functionality. If you feel that you need to do so then maybe you have problems with one or both of your interfaces. Some code examples would be useful to make further comment. That said, and after you clearly think through your design and you still want to proceed, then you may want to look at the assembly attribute "InternalsVisibleTo". This allows you to define internal classes and interfaces in one assembly and have them visible is other assemblies that you explicitly allow access via the "InternalsVisibleTo" attribute. It is very useful for unit testing. Again, I'd carefully think about your design first. I hope this helps. Cheers. James. From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Jeff Sinclair Sent: Wednesday, 28 July 2010 21:15 To: 'ozDotNet' Subject: Dependency injection Hi, I am using Microsoft unity to do dependency inject but I have a small problem. Let's say I have a business layer assembly and a data layer assembly. The data layer exposes 2 interfaces, IDataRepositortyA and IDataRepositoryB. These are both constructed by unity. Now let's say IDataRepositoryA needs to do some low level calls to repository B, say for some type of mash-up. How do I expose a low level function on repository B that really should not be visible to the business layer. Do I just add the low level functions to the public IDataRepositoryB interface, which makes them visible to the business layer? Or do I create a new interface for the extra low level functions? If I make the new interface internal, how does it work with injection ? Jeff
Re: Dependency injection
Hi Jeff,
Most IoC containers (Unity included) allows you to have two type-mappings
pointing to the same destination type. That means you could create a second
interface that is only about those low-level calls.
So you might have
interface IDataRepositoryA { Customer Load(int id); }
interface IDataRepositoryB { Order Load(int id); }
interface ILowLevelDataRepositoryB { AddOrdersToQuery(Query q); }
class DataRepositoryA : IDataRepositoryA {
public DataRepositoryA(ILowLevelDataRepositoryB ordersRepo) {...};
}
class DataRepositoryB : IDataRepositoryB, ILowLevelDataRepositoryB {
}
class BusinessClass {
public BusinessClass(IDataRepositoryB ordersRepo) { ... };
}
var container = new UnityContainer();
container.RegisterType();
container.RegisterType();
// Register Everything else as per normal
now this should hold
var high = container.Resolve();
var low = container.Resolve();
Assert.IsTrue(ReferenceEquals(high, low);
As the RepoA and the Business class rely on different abstractions they
never need to know they're talking to the same object and in time it may
even come to pass that they don't. This is the Interface Segregation
Principle in action: "An consumer class should not be aware of more methods
than it needs to do it's job"
http://www.objectmentor.com/resources/articles/isp.pdf
Regards,
--
Michael M. Minutillo
Indiscriminate Information Sponge
Blog: http://wolfbyte-net.blogspot.com
On Wed, Jul 28, 2010 at 7:44 PM, Jeff Sinclair <
jeff.sinclair.em...@gmail.com> wrote:
> Hi,
>
>
>
> I am using Microsoft unity to do dependency inject but I have a small
> problem.
>
> Let’s say I have a business layer assembly and a data layer assembly. The
> data layer exposes 2 interfaces,
>
> IDataRepositortyA and IDataRepositoryB. These are both constructed by
> unity.
>
>
>
> Now let’s say IDataRepositoryA needs to do some low level calls to
> repository B, say for some type of mash-up.
>
> How do I expose a low level function on repository B that really should not
> be visible to the business layer.
>
> Do I just add the low level functions to the public IDataRepositoryB
> interface, which makes them visible to the business layer?
>
> Or do I create a new interface for the extra low level functions? If I make
> the new interface internal, how does it work with injection ?
>
>
>
> Jeff
>
>
>
RE: Dependency injection
Thanks Michael,
That makes sense.
I was thinking I would need to do some sort of cast
Eg
If (repositoryB is ILowLevelDataRepositoryB)
{
ILowLevelDataRepositoryB lowLevelRepositryB =
(ILowLevelDataRepositoryB) repositryB
.
}
But I really don't need to. They can both just be separate dependencies.
Jeff
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Michael Minutillo
Sent: Wednesday, 28 July 2010 8:22 PM
To: ozDotNet
Subject: Re: Dependency injection
Hi Jeff,
Most IoC containers (Unity included) allows you to have two type-mappings
pointing to the same destination type. That means you could create a second
interface that is only about those low-level calls.
So you might have
interface IDataRepositoryA { Customer Load(int id); }
interface IDataRepositoryB { Order Load(int id); }
interface ILowLevelDataRepositoryB { AddOrdersToQuery(Query q); }
class DataRepositoryA : IDataRepositoryA {
public DataRepositoryA(ILowLevelDataRepositoryB ordersRepo) {...};
}
class DataRepositoryB : IDataRepositoryB, ILowLevelDataRepositoryB {
}
class BusinessClass {
public BusinessClass(IDataRepositoryB ordersRepo) { ... };
}
var container = new UnityContainer();
container.RegisterType();
container.RegisterType();
// Register Everything else as per normal
now this should hold
var high = container.Resolve();
var low = container.Resolve();
Assert.IsTrue(ReferenceEquals(high, low);
As the RepoA and the Business class rely on different abstractions they
never need to know they're talking to the same object and in time it may
even come to pass that they don't. This is the Interface Segregation
Principle in action: "An consumer class should not be aware of more methods
than it needs to do it's job"
http://www.objectmentor.com/resources/articles/isp.pdf
Regards,
--
Michael M. Minutillo
Indiscriminate Information Sponge
Blog: http://wolfbyte-net.blogspot.com
On Wed, Jul 28, 2010 at 7:44 PM, Jeff Sinclair
wrote:
Hi,
I am using Microsoft unity to do dependency inject but I have a small
problem.
Let's say I have a business layer assembly and a data layer assembly. The
data layer exposes 2 interfaces,
IDataRepositortyA and IDataRepositoryB. These are both constructed by unity.
Now let's say IDataRepositoryA needs to do some low level calls to
repository B, say for some type of mash-up.
How do I expose a low level function on repository B that really should not
be visible to the business layer.
Do I just add the low level functions to the public IDataRepositoryB
interface, which makes them visible to the business layer?
Or do I create a new interface for the extra low level functions? If I make
the new interface internal, how does it work with injection ?
Jeff
RE: Dependency Injection
Hi Peter,
Sorry _not_ to address your issues directly.
The promotion patterns and practices is more valuable than the tools these
guys (patterns and practices team) have delivered.
This read gives a very good perspective: The Build Your Own CAB Series.
http://codebetter.com/blogs/jeremy.miller/archive/2007/07/25/the-build-your-
own-cab-series-table-of-contents.aspx
Caliburn is a framework built from the ground up with
OIC/Testability/MVVM/MVP/MVC in mind.
http://caliburn.codeplex.com/
http://www.codeproject.com/KB/WPF/Caliburn_Module_Loading.aspx
Regards,
Nic Roche
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Maddin, Peter
Sent: Thursday, 5 August 2010 7:56 PM
To: ozdotnet@ozdotnet.com
Subject: Dependency Injection
I am experimenting with Dependency Injection in the Microsoft CAB framework.
>From http://blog.irm.se/blogs/home.aspx?App=eric
<http://blog.irm.se/blogs/home.aspx?App=eric&p=11> &p=11
Who says
In this post I'm back covering the CreateNew attribute that you can use in a
class that is instantiated by ObjectBuilder
<http://www.codeplex.com/Wiki/View.aspx?ProjectName=ObjectBuilder> . Marking
a property (or parameter to a method or constructor) with the CreateNew
attributes will set that property to an instance of the object. The instance
itself will of course be built by the ObjectBuilder too. A great example of
when to use this functionality is if you want to implement your GUI with for
example the Model View Presenter (MVP) design pattern. I will only focus on
the View and Presenter here.
I have this basic piece of code
private ContentPresenter _contentPresenter;
[CreateNew]
public ContentPresenter Presenter
{
get { return _contentPresenter; }
set { _contentPresenter = value;}
}
The objectBuilder may instantiate the ContentPresenter for me but I suspect
it wil use the the default parameterless constructer (or expect one).
How can I pass a parameter (in this case a reference to my view that
implements the interface that will be used
By my presenter.
I have a solution that does not use Dependency Injection but would like the
advantages of loose coupling if possible.
Has anyone played (sorry used) the ObjectBuilder in the CAB framework for
dependancy injection of this type and if so how can it be used to specify a
constructor with a parameter.
I have looked at the attributes here
http://www.ikriv.com/en/prog/info/dotnet/CabDependencyInjection/DependencyAt
tributes.html#CreateNew
But that has not helped me much (actually not at all in fact).
I am a sub novice (if one can get that low) with Dependancy Injection.
Regards Peter Maddin
Applications Development Officer
PathWest Laboratory Medicine WA
Phone : +618 9473 3944
Fax : +618 9473 3982
E-Mail : peter.mad...@pathwest.wa.gov.au
The contents of this e-mail transmission outside of the WAGHS network are
intended solely for the named recipient's), may be confidential, and may be
privileged or otherwise protected from disclosure in the public interest.
The use, reproduction, disclosure or distribution of the contents of this
e-mail transmission by any person other than the named recipient(s) is
prohibited. If you are not a named recipient please notify the sender
immediately.
RE: Dependency Injection
> OIC
IOC - fat fingers
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Nic Roche
Sent: Thursday, 5 August 2010 8:43 PM
To: 'ozDotNet'
Subject: RE: Dependency Injection
Hi Peter,
Sorry _not_ to address your issues directly.
The promotion patterns and practices is more valuable than the tools these
guys (patterns and practices team) have delivered.
This read gives a very good perspective: The Build Your Own CAB Series.
http://codebetter.com/blogs/jeremy.miller/archive/2007/07/25/the-build-your-
own-cab-series-table-of-contents.aspx
Caliburn is a framework built from the ground up with
OIC/Testability/MVVM/MVP/MVC in mind.
http://caliburn.codeplex.com/
http://www.codeproject.com/KB/WPF/Caliburn_Module_Loading.aspx
Regards,
Nic Roche
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Maddin, Peter
Sent: Thursday, 5 August 2010 7:56 PM
To: ozdotnet@ozdotnet.com
Subject: Dependency Injection
I am experimenting with Dependency Injection in the Microsoft CAB framework.
>From http://blog.irm.se/blogs/home.aspx?App=eric
<http://blog.irm.se/blogs/home.aspx?App=eric&p=11> &p=11
Who says
In this post I'm back covering the CreateNew attribute that you can use in a
class that is instantiated by ObjectBuilder
<http://www.codeplex.com/Wiki/View.aspx?ProjectName=ObjectBuilder> . Marking
a property (or parameter to a method or constructor) with the CreateNew
attributes will set that property to an instance of the object. The instance
itself will of course be built by the ObjectBuilder too. A great example of
when to use this functionality is if you want to implement your GUI with for
example the Model View Presenter (MVP) design pattern. I will only focus on
the View and Presenter here.
I have this basic piece of code
private ContentPresenter _contentPresenter;
[CreateNew]
public ContentPresenter Presenter
{
get { return _contentPresenter; }
set { _contentPresenter = value;}
}
The objectBuilder may instantiate the ContentPresenter for me but I suspect
it wil use the the default parameterless constructer (or expect one).
How can I pass a parameter (in this case a reference to my view that
implements the interface that will be used
By my presenter.
I have a solution that does not use Dependency Injection but would like the
advantages of loose coupling if possible.
Has anyone played (sorry used) the ObjectBuilder in the CAB framework for
dependancy injection of this type and if so how can it be used to specify a
constructor with a parameter.
I have looked at the attributes here
http://www.ikriv.com/en/prog/info/dotnet/CabDependencyInjection/DependencyAt
tributes.html#CreateNew
But that has not helped me much (actually not at all in fact).
I am a sub novice (if one can get that low) with Dependancy Injection.
Regards Peter Maddin
Applications Development Officer
PathWest Laboratory Medicine WA
Phone : +618 9473 3944
Fax : +618 9473 3982
E-Mail : peter.mad...@pathwest.wa.gov.au
The contents of this e-mail transmission outside of the WAGHS network are
intended solely for the named recipient's), may be confidential, and may be
privileged or otherwise protected from disclosure in the public interest.
The use, reproduction, disclosure or distribution of the contents of this
e-mail transmission by any person other than the named recipient(s) is
prohibited. If you are not a named recipient please notify the sender
immediately.
RE: Dependency Injection
Peter,
As a matter of interest - why do you need a circular dependency between and the
View and the Presenter? I've typically found that the dependency is usually 1
way - ie the View has a dependency on the Presenter (the Supervising Controller
pattern) or the Presenter has the dependency on the View (the Passive View
pattern).
Dave
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On
Behalf Of Maddin, Peter
Sent: Thursday, August 05, 2010 2:56 AM
To: ozdotnet@ozdotnet.com
Subject: Dependency Injection
I am experimenting with Dependency Injection in the Microsoft CAB framework.
>From http://blog.irm.se/blogs/home.aspx?App=eric&p=11
Who says
In this post I'm back covering the CreateNew attribute that you can use in a
class that is instantiated by
ObjectBuilder<http://www.codeplex.com/Wiki/View.aspx?ProjectName=ObjectBuilder>.
Marking a property (or parameter to a method or constructor) with the
CreateNew attributes will set that property to an instance of the object. The
instance itself will of course be built by the ObjectBuilder too. A great
example of when to use this functionality is if you want to implement your GUI
with for example the Model View Presenter (MVP) design pattern. I will only
focus on the View and Presenter here.
I have this basic piece of code
private ContentPresenter _contentPresenter;
[CreateNew]
public ContentPresenter Presenter
{
get { return _contentPresenter; }
set { _contentPresenter = value;}
}
The objectBuilder may instantiate the ContentPresenter for me but I suspect it
wil use the the default parameterless constructer (or expect one).
How can I pass a parameter (in this case a reference to my view that implements
the interface that will be used
By my presenter.
I have a solution that does not use Dependency Injection but would like the
advantages of loose coupling if possible.
Has anyone played (sorry used) the ObjectBuilder in the CAB framework for
dependancy injection of this type and if so how can it be used to specify a
constructor with a parameter.
I have looked at the attributes here
http://www.ikriv.com/en/prog/info/dotnet/CabDependencyInjection/DependencyAttributes.html#CreateNew
But that has not helped me much (actually not at all in fact).
I am a sub novice (if one can get that low) with Dependancy Injection.
Regards Peter Maddin
Applications Development Officer
PathWest Laboratory Medicine WA
Phone : +618 9473 3944
Fax : +618 9473 3982
E-Mail : peter.mad...@pathwest.wa.gov.au<mailto:peter.mad...@pathwest.wa.gov.au>
The contents of this e-mail transmission outside of the WAGHS network are
intended solely for the named recipient's), may be confidential, and may be
privileged or otherwise protected from disclosure in the public interest. The
use, reproduction, disclosure or distribution of the contents of this e-mail
transmission by any person other than the named recipient(s) is prohibited. If
you are not a named recipient please notify the sender immediately.
Re: Dependency Injection
This article provides some options..
http://www.sqlservercentral.com/articles/T-SQL/61918/
<http://www.sqlservercentral.com/articles/T-SQL/61918/>
On Thu, Aug 5, 2010 at 7:56 PM, Maddin, Peter <
peter.mad...@pathwest.wa.gov.au> wrote:
> I am experimenting with Dependency Injection in the Microsoft CAB
> framework.
>
>
>
> From http://blog.irm.se/blogs/home.aspx?App=eric&p=11
>
>
>
> Who says
>
>
>
> In this post I'm back covering the CreateNew attribute that you can use in
> a class that is instantiated by
> ObjectBuilder<http://www.codeplex.com/Wiki/View.aspx?ProjectName=ObjectBuilder>.
> Marking a property (or parameter to a method or constructor) with the
> CreateNew attributes will set that property to an instance of the object.
> The instance itself will of course be built by the ObjectBuilder too. A
> great example of when to use this functionality is if you want to implement
> your GUI with for example the Model View Presenter (MVP) design pattern. I
> will only focus on the View and Presenter here.
>
>
>
> I have this basic piece of code
>
>
>
> private ContentPresenter _contentPresenter;
>
>
>
> [CreateNew]
>
> public ContentPresenter Presenter
>
> {
>
> get { return _contentPresenter; }
>
> set { _contentPresenter = value;}
>
> }
>
>
>
> The objectBuilder may instantiate the ContentPresenter for me but I suspect
> it wil use the the default parameterless constructer (or expect one).
>
>
>
> How can I pass a parameter (in this case a reference to my view that
> implements the interface that will be used
>
> By my presenter.
>
>
>
> I have a solution that does not use Dependency Injection but would like the
> advantages of loose coupling if possible.
>
>
>
> Has anyone played (sorry used) the ObjectBuilder in the CAB framework for
> dependancy injection of this type and if so how can it be used to specify a
> constructor with a parameter.
>
>
>
> I have looked at the attributes here
> http://www.ikriv.com/en/prog/info/dotnet/CabDependencyInjection/DependencyAttributes.html#CreateNew
>
>
>
> But that has not helped me much (actually not at all in fact).
>
>
>
> I am a sub novice (if one can get that low) with Dependancy Injection.
>
>
>
> *Regards Peter Maddin*
> *Applications Development Officer*
> *Path**West Laboratory Medicine WA*
> *Phone : +618 9473 3944*
> *Fax : +618 9473 3982*
> *E-Mail : peter.mad...@pathwest.wa.gov.au*
> *The contents of this e-mail transmission outside of the WAGHS network are
> intended solely for the named recipient's), may be confidential, and may be
> privileged or otherwise protected from disclosure in the public interest.
> The use, reproduction, disclosure or distribution of the contents of this
> e-mail transmission by any person other than the named recipient(s) is
> prohibited. If you are not a named recipient please notify the sender
> immediately.*
>
>
>
Re: Dependency Injection
oops.. replied to wrong email..
pls ignore in this discussion.
On Fri, Aug 6, 2010 at 1:40 PM, Grant Molloy wrote:
> This article provides some options..
> http://www.sqlservercentral.com/articles/T-SQL/61918/
> <http://www.sqlservercentral.com/articles/T-SQL/61918/>
>
> On Thu, Aug 5, 2010 at 7:56 PM, Maddin, Peter <
> peter.mad...@pathwest.wa.gov.au> wrote:
>
>> I am experimenting with Dependency Injection in the Microsoft CAB
>> framework.
>>
>>
>>
>> From http://blog.irm.se/blogs/home.aspx?App=eric&p=11
>>
>>
>>
>> Who says
>>
>>
>>
>> In this post I'm back covering the CreateNew attribute that you can use in
>> a class that is instantiated by
>> ObjectBuilder<http://www.codeplex.com/Wiki/View.aspx?ProjectName=ObjectBuilder>.
>> Marking a property (or parameter to a method or constructor) with the
>> CreateNew attributes will set that property to an instance of the object.
>> The instance itself will of course be built by the ObjectBuilder too. A
>> great example of when to use this functionality is if you want to implement
>> your GUI with for example the Model View Presenter (MVP) design pattern. I
>> will only focus on the View and Presenter here.
>>
>>
>>
>> I have this basic piece of code
>>
>>
>>
>> private ContentPresenter _contentPresenter;
>>
>>
>>
>> [CreateNew]
>>
>> public ContentPresenter Presenter
>>
>> {
>>
>> get { return _contentPresenter; }
>>
>> set { _contentPresenter = value;}
>>
>> }
>>
>>
>>
>> The objectBuilder may instantiate the ContentPresenter for me but I
>> suspect it wil use the the default parameterless constructer (or expect
>> one).
>>
>>
>>
>> How can I pass a parameter (in this case a reference to my view that
>> implements the interface that will be used
>>
>> By my presenter.
>>
>>
>>
>> I have a solution that does not use Dependency Injection but would like
>> the advantages of loose coupling if possible.
>>
>>
>>
>> Has anyone played (sorry used) the ObjectBuilder in the CAB framework for
>> dependancy injection of this type and if so how can it be used to specify a
>> constructor with a parameter.
>>
>>
>>
>> I have looked at the attributes here
>> http://www.ikriv.com/en/prog/info/dotnet/CabDependencyInjection/DependencyAttributes.html#CreateNew
>>
>>
>>
>> But that has not helped me much (actually not at all in fact).
>>
>>
>>
>> I am a sub novice (if one can get that low) with Dependancy Injection.
>>
>>
>>
>> *Regards Peter Maddin*
>> *Applications Development Officer*
>> *Path**West Laboratory Medicine WA*
>> *Phone : +618 9473 3944*
>> *Fax : +618 9473 3982*
>> *E-Mail : peter.mad...@pathwest.wa.gov.au*
>> *The contents of this e-mail transmission outside of the WAGHS network
>> are intended solely for the named recipient's), may be confidential, and may
>> be privileged or otherwise protected from disclosure in the public interest.
>> The use, reproduction, disclosure or distribution of the contents of this
>> e-mail transmission by any person other than the named recipient(s) is
>> prohibited. If you are not a named recipient please notify the sender
>> immediately.*
>>
>>
>>
>
>
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?
RE: Other developers don't like dependency injection
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<http://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
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
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
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
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: &
Re: Other developers don't like dependency injection
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
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
I don't buy the cheaper maintence costs argument, the 5 projects that I am supporting all use spring for DI. I spend half of my time trying to figure out how the damn thing is configured. Although a code based injector without xml config files at least alows you to debug the code and see what is missing. I like DI, but it sure doesn't save time. Davy "When all you have is a hammer, every problem looks like a nail." I feel much the same way about xml -Original Message- From: mike smith Sender: ozdotnet-boun...@ozdotnet.com Date: Thu, 27 Oct 2011 16:46:45 To: ozDotNet Reply-To: ozDotNet Subject: Re: Other developers don't like dependency injection 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
#1 I am a fan of DI and agree about the hard way of selling it. My reasoning for DI is tests. *Tests help us to prevent regression, clarify requirements with clients (BDD) and act as documentation. In order to write some tests we need to inject a dummy. How do we inject a dummy? --> DI* #2 I am not a big fan of IoC containers either. I have similar experiences as Justin documented here (although the setup of dependencies can become messy without IoCC) http://codelikebozo.com/breaking-up-with-ioc .peter.gfader. (current mood = happy) http://blog.gfader.com On Thu, Oct 27, 2011 at 10:05 AM, wrote: > ** I don't buy the cheaper maintence costs argument, the 5 projects that > I am supporting all use spring for DI. > I spend half of my time trying to figure out how the damn thing is > configured. > > Although a code based injector without xml config files at least alows you > to debug the code and see what is missing. > > I like DI, but it sure doesn't save time. > > Davy > > "When all you have is a hammer, every problem looks like a nail." I feel > much the same way about xml > -- > *From: * mike smith > *Sender: * ozdotnet-boun...@ozdotnet.com > *Date: *Thu, 27 Oct 2011 16:46:45 +1100 > *To: *ozDotNet > *ReplyTo: * ozDotNet > *Subject: *Re: Other developers don't like dependency injection > > 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 > > -- .peter.gfader. Current mood = happy! Check this before you go live http://blog.gfader.com/2011/07/website-check-list-part-1-aspnet-4.html
Re: Other developers don't like dependency injection
As others have said try selling it differently...but don't expect miracles because that's what's needed with some developers. I've run into a few. If there is true benefit to DI in your project(s) then push for it but don't get too upset if you don't get your way. I'm curious though, how is unit testing happening without at least some DI? Or are only parts of the system being unit tested and the rest ignored? On Thu, Oct 27, 2011 at 2:15 PM, 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
I'm actually wishy washy with DI as well, at first I was pretty damn excited with it, but I suppose it depends on the circumstance and use case. If you're at work and you're pressed on time and budget, you'd need to do some big convincing to show the future benefits. Furthermore like everyone has said, to sell a feature or a toolset, you really need to nail it at a different perspective, rather than saying DI is awesome, I've used it, it's great for decoupling. Like if you drop subtle problems in the design/architecture of the system that DI can solve, it might communicate your point in a more applicable way. On Thu, Oct 27, 2011 at 7:53 PM, DotNet Dude wrote: > As others have said try selling it differently...but don't expect > miracles because that's what's needed with some developers. I've run > into a few. If there is true benefit to DI in your project(s) then > push for it but don't get too upset if you don't get your way. > > I'm curious though, how is unit testing happening without at least > some DI? Or are only parts of the system being unit tested and the > rest ignored? > > > On Thu, Oct 27, 2011 at 2:15 PM, 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? > > >
