2013-12-16 8 views
14

Jestem zaznajomiony z MVC, ale staram się nauczyć WPF z programem Ninject. Czy ktoś może podać mi jakiś przykład lub referencję?Jak używać programu Ninject w aplikacji WPF

+1

Czy obejrzałeś Ninject [dokumentacja na ich stronie i GitHub] (https://github.com/ninject/ninject/wiki/Getting-Started)? –

+0

Już patrzę na ich stronę. ale wciąż nie rozumiem ... przepraszam za zmarnowanie twojego czasu. –

+0

To dobrze, ale zawęzić pytanie do czegoś bardziej konkretnego. Z jakimi problemami się borykasz i co próbowałeś do tej pory? –

Odpowiedz

53

Jak już powiedziałem w swoim komentarzu do twojego OP, wszystkie potrzebne informacje są dostępne w ramach Ninject documentation. Powiedział, że można się spierać, że łatwo jest zgubić się w jego obszernej dokumentacji, jeśli nie jesteś zaznajomiony z Ninject i/lub DI.

Istnieje kilka tutoriali online, z których this one Myślałem, że był szczególnie pouczający. Mimo że podaje przykład przy użyciu console application, zasady działania tego robota pozostają takie same.

Niezależnie od rodzaju aplikacji, konfigurujesz kontener w punkcie wejścia do aplikacji;

  • Console app - Main
  • WPF - App (chyba, że ​​używasz ramy w takim przypadku można zapewnić niestandardową inicjującego)
  • ASP.NET - Nie mam pojęcia, może ktoś mógłby mnie oświecić

ZASTRZEŻENIE nie uważają się za autorytet w Ninject lub DI, poniżej jest po prostu szybki przykład, jak rozumiem te dwa obiekty mogą być używane w połączeniu ze sobą.

Na przykład pozwól nam pracować z przykładami podanymi w dokumentacji Ninject.

1) Tworzenie aplikacji WPF nazwie NinjectIoC

2) Zastosowanie Nuget dodać odwołanie do projektu

3) Otwórz App.xamlNinject i usunąć właściwość StartupUri od Application element, aby Twój App.xaml wyglądał następująco:

<Application x:Class="NinjectIoC.App" 
      xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
      xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"> 
    <Application.Resources> 

    </Application.Resources> 
</Application> 

Powodem, dla którego to robimy, jest fakt, że właściwość StartupUri informuje aplikację WPF, którą kontrolę interfejsu użytkownika można początkowo wyświetlić po uruchomieniu aplikacji. Zamierzamy użyć Ninject, aby wyświetlić naszą początkową kontrolę interfejsu użytkownika.

4) Otwórz App.xaml.cs. Tutaj będziemy konfigurować Ninjectcontainer lub Kernel, aby używać terminologii Ninject. Mamy override metodę, abyśmy mogli skonfigurować naszą container, a następnie zainicjować aplikację, jak byśmy chcieli.Aktualizować zawartość swojej App.xaml.cs wyglądać następująco:

namespace NinjectIoC 
{ 
    using Ninject; 
    using System.Windows; 

    public partial class App 
    { 
     private IKernel container; 

     protected override void OnStartup(StartupEventArgs e) 
     { 
      base.OnStartup(e); 
      ConfigureContainer(); 
      ComposeObjects(); 
      Current.MainWindow.Show(); 
     } 

     private void ConfigureContainer() 
     { 
      this.container = new StandardKernel(); 
      container.Bind<IWeapon>().To<Sword>().InTransientScope(); 
     } 

     private void ComposeObjects() 
     { 
      Current.MainWindow = this.container.Get<MainWindow>(); 
      Current.MainWindow.Title = "DI with Ninject"; 
     } 
    } 
} 

Krótka explination:

4,1)OnStartup - Override the OnStartup method so that we may configure our kontener i zainicjować aplikacji jak pragniemy.

4.2) - Poinformuj nasz container o tym, jak chcielibyśmy rozwiązać nasze konkretne typy. W tym przykładzie jest o wiele więcej, niż pokazałem, jednak jest o wiele więcej niż to, co pokazałem. Istnieją tematy takie jak Multi Binding, Binding Conventions i Kernel Modules, dla których najlepiej się o tym uczysz od official documentation.

4,3)ComposeObjects - Po usunięciu właściwość StartupUri z App.xaml musimy poinformować aplikację, która UI kontrola chcielibyśmy go używać do MainWindow. Oprócz pytania o nasze container, aby użyć MainWindow jako naszego MainWindow, ustawiamy również właściwość . Ponownie możesz tu wykonać inne zadania dla ręcznego komponowania obiektów.

Nie musisz oddzielać kroków, jak ja powyżej, dla tego wymyślonego przykładu byłoby bardziej sensownie nie zawracać sobie głowy. W miarę jak aplikacja rośnie, a Ty zaczynasz robić bardziej wyrafinowane rzeczy za pomocą container, oddzielenie niektórych etapów zaczyna sprawiać, że konfiguracja container staje się łatwiejsza w zarządzaniu. Wybór nalezy do ciebie.

5) Następny otwarty MainWindow.xaml, skopiuj i wklej następujący:

<Window x:Class="NinjectIoC.MainWindow" 
     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
     Height="78" Width="362"> 
    <Grid> 
     <Button Content="Button" HorizontalAlignment="Left" Margin="269,10,0,0" VerticalAlignment="Top" Width="75" Click="Attack"/> 
     <TextBox x:Name="Target" HorizontalAlignment="Left" Height="23" Margin="10,10,0,0" VerticalAlignment="Top" Width="254"/> 
    </Grid> 
</Window> 

nie będę niepokoić tłumacząc powyższe, jak powinno być oczywiste, co się dzieje.

6) Wreszcie otwarty MainWindow.xaml.cs i aktualizować go w następujący sposób:

namespace NinjectIoC 
{ 
    using System.Windows; 

    public partial class MainWindow 
    { 
     private readonly IWeapon weapon; 

     public MainWindow(IWeapon weapon) 
     { 
      this.weapon = weapon; 
      InitializeComponent(); 
     } 

     private void Attack(object sender, RoutedEventArgs e) 
     { 
      this.weapon.Hit(this.Target.Text); 
     } 
    } 

    public class Sword : IWeapon 
    { 
     public void Hit(string target) 
     { 
      MessageBox.Show(@"I swing and thrust my sword about like a mad man at " + target); 
     } 
    } 

    public interface IWeapon 
    { 
     void Hit(string target); 
    } 
} 

Znowu zrobię to krótkie jak to, co się dzieje powyżej nie ma nic wspólnego z konfiguracją Ninject i powinno być po raz kolejny oczywiste, co się dzieje.

Najważniejszą rzeczą, na którą należy zwrócić uwagę, jest argument, którego oczekuje konstruktor MainWindow; IWeapon. Być może zadajesz sobie pytanie: Jak to się dzieje, ponieważ nie tworzę konkretnej implementacji Weapon w dowolnym miejscu?

Dobrze podczas metody w App.xaml.cs poinformowaliśmy container jak chcielibyśmy, aby rozwiązać zależności dla IWeapon:

container.Bind<IWeapon>().To<Sword>().InTransientScope(); 

Powyższy opowiada container że wszędzie napotka zależność dla IWeapon chcielibyśmy aby dostarczyć instancję z Weapon.Po prośbą o container determinację (Get) nasz początkowy MainWindow sterowania, za pomocą następujących czynności:

Current.MainWindow = this.container.Get<MainWindow>(); 

container przyjrzał się jej konstruktorów i zdeterminowany konstruktora z większością argumentów to zrozumiałe. W tym przykładzie to konstruktor wymagał implementacji IWeapon i och, container wie, jak rozwiązać tę zależność, ponieważ powiedzieliśmy jej, jak to zrobić wcześniej w .

Zakładając, że ani Ty, ani ja nie popełniliśmy żadnych błędów w powyższym kodzie, naciśnięcie klawisza F5 powinno uruchomić aplikację i powinieneś zobaczyć małe okienko z TextBox i Button. Wpisz coś w numerze , a następnie naciśnij przycisk Button, a powinieneś zobaczyć kontrolkę MessageBox informującą cię, że machnąłeś mieczem jak "mad man" na kimkolwiek lub cokolwiek, co wpisałeś w TextBox.


Jest znacznie więcej zarówno Ninject i DI niż opisałem tutaj. Na przykład istnieją całe książki na temat DI, takie jak this one by Mark Seeman.

Mamy nadzieję, że powyższe informacje pomogą Ci w podstawowym punkcie wyjścia i dalszych krokach związanych z przygodami z Ninject i DI.

+0

o dzięki, dziękuję bardzo ... pomóż mi więcej ... –

+0

@noviankristianto - Cieszę się, że mogę Ci pomóc Jeśli znalazłeś moją odpowiedź, pomóż jej albo ująć w obietnicę, albo zaznaczyć jako odpowiedź zarówno dla mnie, jak i dla społeczności. [: –

+0

hahaha sorry, done oznaczyć odpowiedź –

Powiązane problemy