Wstrzyknięcie konstruktora kontra wstrzykiwanie ustawiające dla właściwości nadrzędnej

Question

Próbuję znaleźć najlepszy sposób użycia wtrysku zależności dla jakiegoś starszego kodu, który zajmie dużo czasu refaktorowi i musi być wykonywany stopniowo. Większość starych klas użyć „dominująca” właściwość do określania różnych rzeczy i własnością rodzic często mijają się za pomocą argumentu konstruktora następująco:

constructor TParentObject.Create; 
begin 
    FChildObject := TChildObject.Create(Self); 
end; 

constructor TChildObject.Create(AParent: TParentObject) 
begin 
    FParent := AParent; 
end; 

Jest to dość typowe dla naszej bazy kodu starszego typu. Jednak podczas przechodzenia do interfejsów i iniekcji konstruktora obiekt macierzysty nie jest znany w ramach Spring4D podczas tworzenia obiektu Child. Więc po prostu dostanie nowego rodzica, ale nie istniejącego. Oczywiście mogę utworzyć właściwość getter/setter, ale to wskazywałoby na "opcjonalną" właściwość klasy, która jest naprawdę obowiązkową własnością. Zobacz poniższy kod, aby uzyskać więcej wyjaśnień:

unit uInterfaces; 

interface 

uses 
    Spring.Collections; 

type 

    IChildObject = interface; 

    IParentObject = interface 
    ['{8EA8F9A2-E627-4546-8008-0A77DA2B16F1}'] 
    function GetSomethingRequiredByChild: string; 
    procedure SetSomethingRequiredByChild(const Value: string); 
    property SomethingRequiredByChild: string read GetSomethingRequiredByChild write SetSomethingRequiredByChild; 
    function GetChild: IChildObject; 
    property Child: IChildObject read GetChild; 
    end; 

    // This introduces a property getter/setter 
    // However it also implies that Parent can be NIL which it cannot 
    IChildObject = interface 
    ['{ECCA09A6-4A52-4BE4-A72E-2801160A9086}'] 
    function GetParent: IParentObject; 
    procedure SetParent(const Value: IParentObject); 
    property Parent: IParentObject read GetParent write SetParent; 
    end; 

    TParentObject = class(TInterfacedObject, IParentObject) 
    private 
    FChild: IChildObject; 
    FSomethingRequiredByChild: string; 
    function GetChild: IChildObject; 
    function GetSomethingRequiredByChild: string; 
    procedure SetSomethingRequiredByChild(const Value: string); 
    public 
    constructor Create; 
    end; 

    TChildObject = class(TInterfacedObject, IChildObject) 
    private 
    FParent: IParentObject; 
    function GetParent: IParentObject; 
    procedure SetParent(const Value: IParentObject); 
    public 
    // This requries a Parent object, but how does the Spring4D resolve the correct parent? 
    constructor Create(const AParent: IParentObject); 
    end; 

implementation 

uses 
    Spring.Services; 

{ TParentObject } 

constructor TParentObject.Create; 
begin 
    // Here is the old way... 
    FChild := TChildObject.Create(Self); // Old way of doing it 

    // This is the Service Locator way... 
    FChild := ServiceLocator.GetService<IChildObject>; 
    // I would prefer that the Parent is assigned somehow by the Service Locator 
    // IS THIS POSSIBLE - or am I dreaming? 
    FChild.Parent := Self; 
end; 

function TParentObject.GetChild: IChildObject; 
begin 
    Result := FChild; 
end; 

function TParentObject.GetSomethingRequiredByChild: string; 
begin 
    Result := FSomethingRequiredByChild; 
end; 

procedure TParentObject.SetSomethingRequiredByChild(const Value: string); 
begin 
    FSomethingRequiredByChild := Value; 
end; 

{ TChildObject } 

constructor TChildObject.Create(const AParent: IParentObject); 
begin 
    FParent := AParent; 
end; 

function TChildObject.GetParent: IParentObject; 
begin 
    Result := FParent; 
end; 

procedure TChildObject.SetParent(const Value: IParentObject); 
begin 
    FParent := Value; 
end; 

end. 

Może jest jakaś metoda, która może być używana, że ​​nie jestem świadomy, aby ustawić obiektu nadrzędnego za pomocą ramy DI?

Mam nadzieję, że to pytanie jest jasne, co staram się osiągnąć. W razie potrzeby chętnie podam więcej opisu/kodu.

Answer 1

Przede wszystkim nie należy używać lokalizatora usług do zastępowania wywołań ctor. To tylko pogarsza sprawę. Wiem, że ludzie myślą, że są mądrzy, ale tak naprawdę zastępują jedną prostą zależność na innej klasie zależnością od jakiegoś globalnego stanu oraz wymóg, że jakiś inny kod z (kontroli klas) umieszcza zależność w kontenerze. To nie powoduje łatwiejszego, ale trudniejszego do utrzymania kodu.

Plus wszystkie powody, dla których powinieneś trzymać się z dala od tego. Lokalizator usług może mieć ograniczone zastosowanie w starszej aplikacji do wprowadzenia głównego komponentu w środku aplikacji, aby uruchomić DI z tego punktu, ale nie w taki sposób, jaki jest wyświetlany.

Jeśli rodzic potrzebuje dziecka, po prostu go wstrzyknij. Problem polega na tym, że jeśli chcesz stworzyć rodzica, najpierw potrzebujesz dziecka, ale dziecko potrzebuje rodzica. Jak to osiągnąć? Istnieją dwa rozwiązania. Jednak jeden z nich nie jest kompatybilny z pure DI.

raz pierwszy pokazać drogę przy użyciu dostarczonych przez fabrykę pojemnika (wymaga najnowszej wersji rozwijać gałąź jak od chwili nadania):

unit ParentChildRelationShip.Types; 

interface 

uses 
    SysUtils, 
    Spring, 
    Spring.Container.Common; 

type 
    IChildObject = interface; 

    IParentObject = interface 
    ['{8EA8F9A2-E627-4546-8008-0A77DA2B16F1}'] 
    function GetChild: IChildObject; 
    property Child: IChildObject read GetChild; 
    end; 

    IChildObject = interface 
    ['{ECCA09A6-4A52-4BE4-A72E-2801160A9086}'] 
    function GetParent: IParentObject; 
    property Parent: IParentObject read GetParent; 
    end; 

    TParentObject = class(TInterfacedObject, IParentObject) 
    private 
    FChild: IChildObject; 
    function GetChild: IChildObject; 
    public 
    constructor Create(const childFactory: IFactory<IParentObject, IChildObject>); 
    end; 

    TChildObject = class(TInterfacedObject, IChildObject) 
    private 
    FParent: WeakReference<IParentObject>; 
    function GetParent: IParentObject; 
    public 
    constructor Create(const AParent: IParentObject); 
    end; 

implementation 

{ TParentObject } 

constructor TParentObject.Create; 
begin 
    FChild := childFactory(Self); 
end; 

function TParentObject.GetChild: IChildObject; 
begin 
    Result := FChild; 
end; 

{ TChildObject } 

constructor TChildObject.Create(const AParent: IParentObject); 
begin 
    FParent := AParent; 
end; 

function TChildObject.GetParent: IParentObject; 
begin 
    Result := FParent; 
end; 

end. 

program ParentChildRelation; 

{$APPTYPE CONSOLE} 

uses 
    SysUtils, 
    Spring.Container, 
    Spring.Container.Common, 
    ParentChildRelationShip.Types in 'ParentChildRelationShip.Types.pas'; 

procedure Main; 
var 
    parent: IParentObject; 
    child: IChildObject; 
begin 
    GlobalContainer.RegisterType<IParentObject,TParentObject>; 
    GlobalContainer.RegisterType<IChildObject,TChildObject>; 
    GlobalContainer.RegisterFactory<IFactory<IParentObject,IChildObject>>(TParamResolution.ByValue); 
    GlobalContainer.Build; 
    parent := GlobalContainer.Resolve<IParentObject>; 
    child := parent.Child; 
    Assert(parent = child.Parent); 
end; 

begin 
    try 
    Main; 
    except 
    on E: Exception do 
     Writeln(E.Message); 
    end; 
    ReportMemoryLeaksOnShutdown := True; 
end. 

Jeśli nie chcesz korzystać z pojemnika zaopatrzonego fabrykę ty jawnie zarejestruj się sam. Następnie RegisterFactory wezwanie otrzymuje z tego:

GlobalContainer.RegisterInstance<TFunc<IParentObject,IChildObject>>(
    function(parent: IParentObject): IChildObject 
    begin 
     Result := GlobalContainer.Resolve<IChildObject>([TValue.From(parent)]); 
    end); 

a parametr konstruktora można zmienić TFunc<...> gdyż nie potrzebują RTTI dla tej metody (dlatego potrzebne IFactory<...> w drugim przypadku).

Druga wersja wykorzystuje wtrysk polowy i dlatego jest niekompatybilna z DI - bądź ostrożny, pisząc kod w ten sposób, ponieważ nie działa bez użycia kontenera lub RTTI - na przykład, jeśli chcesz przetestować te klasy, może być trudno je skomponować bez pojemnika. Ważną częścią jest tutaj PerResolve, który nakazuje kontenerowi ponowne użycie raz rozstrzygniętej instancji, gdy potrzebna jest inna zależność, którą może zaspokoić.

unit ParentChildRelationShip.Types; 

interface 

uses 
    SysUtils, 
    Spring; 

type 
    IChildObject = interface; 

    IParentObject = interface 
    ['{8EA8F9A2-E627-4546-8008-0A77DA2B16F1}'] 
    function GetChild: IChildObject; 
    property Child: IChildObject read GetChild; 
    end; 

    IChildObject = interface 
    ['{ECCA09A6-4A52-4BE4-A72E-2801160A9086}'] 
    function GetParent: IParentObject; 
    property Parent: IParentObject read GetParent; 
    end; 

    TParentObject = class(TInterfacedObject, IParentObject) 
    private 
    [Inject] 
    FChild: IChildObject; 
    function GetChild: IChildObject; 
    end; 

    TChildObject = class(TInterfacedObject, IChildObject) 
    private 
    FParent: WeakReference<IParentObject>; 
    function GetParent: IParentObject; 
    public 
    constructor Create(const AParent: IParentObject); 
    end; 

implementation 

function TParentObject.GetChild: IChildObject; 
begin 
    Result := FChild; 
end; 

{ TChildObject } 

constructor TChildObject.Create(const AParent: IParentObject); 
begin 
    FParent := AParent; 
end; 

function TChildObject.GetParent: IParentObject; 
begin 
    Result := FParent; 
end; 

end. 

program ParentChildRelation; 

{$APPTYPE CONSOLE} 

uses 
    SysUtils, 
    Spring.Container, 
    Spring.Container.Common, 
    ParentChildRelationShip.Types in 'ParentChildRelationShip.Types.pas'; 

procedure Main; 
var 
    parent: IParentObject; 
    child: IChildObject; 
begin 
    GlobalContainer.RegisterType<IParentObject,TParentObject>.PerResolve; 
    GlobalContainer.RegisterType<IChildObject,TChildObject>; 
    GlobalContainer.Build; 
    parent := GlobalContainer.Resolve<IParentObject>; 
    child := parent.Child; 
    Assert(parent = child.Parent); 
end; 

begin 
    try 
    Main; 
    except 
    on E: Exception do 
     Writeln(E.Message); 
    end; 
    ReportMemoryLeaksOnShutdown := True; 
end. 

Przy okazji. Obserwuj swoje referencje między rodzicem a dzieckiem podczas korzystania z interfejsów. Jeśli będą się nawzajem odnosić, dostaniesz wycieki pamięci.Możesz rozwiązać ten problem, używając słabej referencji z jednej strony (zazwyczaj odniesienia dla rodziców w dziecku).