1

Topic: As without transferring the link to the container (DI)

Write what to transfer the link on IContainer badly and how to be if it is necessary to create a copy of a class in the course of calculations and to initialize its fields, for example with container transmission, for example class A {IContainer container; A (IContainer container) {this.container = container;} IEnumerable <B> CalculateSomething () {return Enumerable. Range (1,100).Select (i => container. Resolve <B> (new TypedParameter (type (int), i));}} As such scenarios correctly are under construction without transmission and storage of links to containers?

2

Re: As without transferring the link to the container (DI)

Hello, okon, you wrote: O> As such scenarios correctly are under construction without transmission and storage of links to containers? The task consists in creation of a copy of a class so after all? And the similar task solve template Factory. public class A {private IMyFactory _myFactory; public A (IMyFactory myFactory) {_myFactory = myFactory;} public IEnumerable <IMyClass> CalculateSomething () {return Enumerable. Range (1,100).Select (i => _myFactory. CreateSomething (i));}}

3

Re: As without transferring the link to the container (DI)

Hello, Doc, you wrote: Doc> Hello, okon, you wrote: O>> As such scenarios correctly are under construction without transmission and storage of links to containers? Doc> the task consists in creation of a copy of a class so after all? And the similar task solve template Factory. Doc> Doc> public class A Doc> {Doc> private IMyFactory _myFactory; Doc> public A (IMyFactory myFactory) Doc> {Doc> _myFactory = myFactory; Doc>} Doc> public IEnumerable <IMyClass> CalculateSomething () Doc> {Doc> return Enumerable. Range (1,100).Select (i => _myFactory. CreateSomething (i)); Doc>} Doc>} Doc> it is possible, but it is not clear yet as will look inside Factory. CreateSomething, after all in it it is necessary or to create  manually, or somehow  dependences. public class MyFactory: IMyFactory {IContainer container; public MyFactory (IContainer container) {this.container = container;} IMyClass CreateSomething (int i) {return container. Resolve <IMyClass> (new TypedParameter (type (int), i);}} i.e. is not clear how to get rid yet from container since the designer of type  IMyClass can accept mass of arguments which it would be desirable to take from the container instead of to transfer explicitly.

4

Re: As without transferring the link to the container (DI)

Hello, okon, you wrote: O> it is possible, but it is not clear yet as will look inside Factory. CreateSomething, after all in it it is necessary or to create  manually, or somehow  dependences. The factory creates quite specific  quite specific (but only to it known) types. If it is necessary to create other types - there is other factory. If look attentively, implementation Factory already abstraction and  in a class as at the interface. Method CreateSomething should return interface ISomething Actually more abstractions / interfaces it is not required.

5

Re: As without transferring the link to the container (DI)

Hello, okon, you wrote: O> it is possible, but it is not clear yet as will look inside Factory. CreateSomething, after all in it it is necessary or to create  manually, or somehow  dependences. class A {Func <int, B> bFactory; A (Func <int, B> bFactory) {this.bFactory = bFactory;} IEnumerable <B> CalculateSomething () {return Enumerable. Range (1, 100).Select (i => bFactory (i));}} ////////////////////////////////// var b = new A (i => container. Resolve <B> (new TypedParameter (typeof (int), i)))... <<RSDN@Home 1.3.110 alpha 5 rev. 62>>

6

Re: As without transferring the link to the container (DI)

_R _> _R _> ////////////////////////////////// _R _> var b = new A (i => container. Resolve <B> (new TypedParameter (typeof (int), i))) _R _> But the link to the container and it is not clear where to take, it exists only at  a root and further it do not recommend to transfer.

7

Re: As without transferring the link to the container (DI)

Hello, Doc, you wrote: Doc> Hello, okon, you wrote: O>> it is possible, but it is not clear yet as will look inside Factory. CreateSomething, after all in it it is necessary or to create  manually, or somehow  dependences. Doc> the factory creates quite specific  quite specific (but only to it known) types. Doc> if it is necessary to create other types - there is other factory. Doc> if look attentively, implementation Factory already abstraction and  in a class as at the interface. Doc> method CreateSomething should return interface ISomething Doc> Actually more abstractions / interfaces it is not required. Means that B can accept many arguments of the designer, for example B (int I, IFoo foo, IBar bar) {} In turn Foo: IFoo the difficult designer with set of parameters too can have, through Resolve we calculate them the automatic machine. In the container we register IFoo, IBar and in factory as it is offered  them? Factory {B CreateB (int I) {return new B (i, new Foo (new X (), new Y ()), new Bar (new Z (), new X ());}} here so it would not be desirable to do, since it is rigidly set  Foo, Bar and it is difficult for substitution for the same tests.

8

Re: As without transferring the link to the container (DI)

Hello, okon, you wrote: O> Here so it would not be desirable to do, since it is rigidly set  Foo, Bar and it is difficult for substitution for the same tests. And it is not necessary. The factory knows specific types (type) and creates only any group of objects (or one object). All of them are connected by the purpose, logically etc. All that is necessary for creation of this group - dependences already factories. And to know these types factory should not. I.e. public class MyFabric: IMyFabric {public MyFabric (IFoo foo, IBar bar) {...} public ISomething CreateSomething (int i) {return new Something (i, foo, bar);//or for example//return new Something (foo (i), bar);}} PS: By the way, service locator IMHO not always an antipattern. In certain cases it is quite applicable. But, probably, it is a subject for separate talk.

9

Re: As without transferring the link to the container (DI)

By the way, dependences can be transferred not only through the designer, but also through properties and method parameters. Therefore still there is a variant with public ISomething CreateSomething (int i, IFoo foo, IBar bar) {...} and they are already implemented through the designer of the causing side

10

Re: As without transferring the link to the container (DI)

Hello, okon, you wrote: O> Write what to transfer the link on IContainer badly Who writes? Than badly?

11

Re: As without transferring the link to the container (DI)

Hello, Sharov, you wrote: S> Hello, okon, you wrote: O>> Write what to transfer the link on IContainer badly, S> Who writes? Than badly? Who any more I do not remember, but the sense was such that all dependence graph should be defined in one place, instead of to be spread on the code.

12

Re: As without transferring the link to the container (DI)

Hello, okon, you wrote: O> Who any more I do not remember, but the sense was such that all dependence graph should be defined in one place, instead of to be spread on the code. It is logical, but it is necessary to transfer the link to the container, differently as objects will form?

13

Re: As without transferring the link to the container (DI)

Hello, okon, you wrote: O> Write what to transfer the link on IContainer badly, O> and how to be if it is necessary to create a copy of a class in the course of calculations and to initialize its fields, for example with container transmission, for example O> As such scenarios correctly are under construction without transmission and storage of links to containers? In Springe it becomes as that so @Bean public FactoryType factoryType (Dependency1 dep1, Dependency2 dep2) {return new FactoryType (dep1, dep2);} Here as a matter of fact the factory which creates object of type FactoryType with dependences dep1, dep2.  explicitly nobody causes This method, it is caused by the container and transfers there necessary dependences.

14

Re: As without transferring the link to the container (DI)

Hello, Sharov, you wrote: S> Hello, okon, you wrote: O>> Who any more I do not remember, but the sense was such that all dependence graph should be defined in one place, instead of to be spread on the code. S> it is logical, but it is necessary to transfer the link to the container, differently as objects will form? It is meant that Resolve becomes once for root object, and remaining dependences sit in designers and are calculated by the automatic machine.

15

Re: As without transferring the link to the container (DI)

Hello, okon, you wrote: O> It is meant that Resolve becomes once for root object, and remaining dependences sit in designers and are calculated by the automatic machine. And why I cannot for different objects, i.e. types, to do Resolve? For type on the container?

16

Re: As without transferring the link to the container (DI)

Hello, Sharov, you wrote: S> Hello, okon, you wrote: O>> It is meant that Resolve becomes once for root object, and remaining dependences sit in designers and are calculated by the automatic machine. S> and why I cannot for different objects, i.e. types to do Resolve? For type on the container? The main idea I so understand to do this all at container adjustment including if something is necessary  once then, there is a function somehow so void RegisterTypesInContainer () {... container. Register <Func <MyClass>> (() => container. Resolve <MyClass> ());...} and then somewhere in the code instead of doing container. Resolve () public class Foo {Foo (Func <MyClass> myClassFactory) {MyClass instance = myClassFactory ();}} instead of Func <MyClass> () it is possible to do any IMyClassFactory

17

Re: As without transferring the link to the container (DI)

Hello, okon, you wrote: O> and then somewhere in the code instead of doing container. Resolve () O> O> public class Foo O> {O> Foo (Func <MyClass> myClassFactory) O> {O> MyClass instance = myClassFactory (); O>} O>} O> And the factory whence undertook? It too it is necessary resolve'. Besides, we can adjust the container at creation (resolve) type to use factory. I.e. from the link to the container with subsequent resolve we did not leave.

18

Re: As without transferring the link to the container (DI)

Hello, Sharov, you wrote: S> Hello, okon, you wrote: O>> and then somewhere in the code instead of doing container. Resolve () O>> O>> public class Foo O>> {O>> Foo (Func <MyClass> myClassFactory) O>> {O>> MyClass instance = myClassFactory (); O>>} O>>} O>> S> And the factory whence undertook? It too it is necessary resolve'. Besides, we can adjust the container at creation (resolve) type to use factory. I.e. from the link to the container with subsequent resolve we did not leave. It  the automatic machine, I in an example registered it there where  everything, Foo will be somewhere in hierarchy and it  the automatic machine. For example the most simple hierarchy public class RootClass {public RootClass (Foo foo) {...} } After container creation it is caused  . The container is mentioned only in one place in method CreateContainer and more it is not required void CreateContainer () {container. Register <Func <MyClass>> (() => container. Resolve <MyClass> ()); Root = container. Resolve <RootClass> ();}

19

Re: As without transferring the link to the container (DI)

Hello, okon, you wrote: O> after container creation it is caused  . O> the Container is mentioned only in one place in method CreateContainer and more it is not required O> O> void CreateContainer () O> {O> container. Register <Func <MyClass>> (() => container. Resolve <MyClass> ()); O> Root = container. Resolve <RootClass> (); O>} O> It will be mentioned in each class where at least it is required RootClass or still that. I.e. besides, it everywhere it is necessary , at least through the designer of a class, in the same place, in the designer to receive from it all necessary and to forget about it.

20

Re: As without transferring the link to the container (DI)

Hello, Doc, you wrote: Doc> PS: By the way, service locator IMHO not always an antipattern. In certain cases it is quite applicable. But, probably, it is a subject for separate talk. And prompt in what cases application locator service it is justified? To me from my experience only 1 time was necessary to face it when under SharePoint wrote - but there on another generally it was impossible. Whether there is still what or practical cases of defensible application a locator service

21

Re: As without transferring the link to the container (DI)

Hello, Sharov, you wrote: S> Hello, okon, you wrote: O>> after container creation it is caused  . O>> the Container is mentioned only in one place in method CreateContainer and more it is not required O>> O>> void CreateContainer () O>> {O>> container. Register <Func <MyClass>> (() => container. Resolve <MyClass> ()); O>> Root = container. Resolve <RootClass> (); O>>} O>> S> It will be mentioned in each class where at least it is required RootClass or still that. I.e. besides, it everywhere it is necessary , at least through the designer of a class, in the same place, in the designer to receive from it S> all necessary and to forget about it. For RootClass not absolutely I understood, for example if to us is necessary RootClass somewhere inside we simply we specify it in the designer Here for example, all  without container transmission public class RootClass {RootClass (Foo foo) {}} public class MyClass {public MyClass (RootClass root) {}} public class Foo {Foo (Func <MyClass> myClassFactory) {var myClass = myClassFactory ();}}

22

Re: As without transferring the link to the container (DI)

Hello, okon, you wrote: O> it is possible, but it is not clear yet as will look inside Factory. CreateSomething, after all in it it is necessary or to create  manually, or somehow  dependences. It is not necessary to make a fuss with factories-wrappers over the container. The factory should create simply copies of specific classes, transferring all of them long-living dependences through itself. The sense of such factory that it forms at once, holds in itself the necessary dependences, and on demand creates short-lived objects to which these dependences are necessary.

23

Re: As without transferring the link to the container (DI)

Hello, okon, you wrote: O> Write what to transfer the link on IContainer badly Under badly here meant a case when the class receives the container and itself pulls from it the dependences, instead of receives them through arguments of the designer. If at us any class permanently creates any objects that often and happens, it depends on factory of these objects, here let the container and transfers factory to it as dependence. P.S. As factory, other copy of the container "charged" under this class is often transferred. So at us and all dependences are registered in one place and the class cannot  that superfluous.

24

Re: As without transferring the link to the container (DI)

Hello, okon, you wrote: O> Write what to transfer the link on IContainer badly, O> and how to be if it is necessary to create a copy of a class in the course of calculations and to initialize its fields, for example with container transmission, for example O> As such scenarios correctly are under construction without transmission and storage of links to containers? class a {private Func <B> _getB; public A (Func <B> getB) {} IEnumerable <B> CalculateSomething () {return Enumerable. Range (1,100).Select (i => _getB ());}}