Quelle est donc la différence entre Ninject & un moqueur cadre comme RhinoMock ou moq? Je google de cette mais il est encore difficile.
Réponses
Trop de publicités?
Ninject est l'Injection de Dépendance pour .NET.
RhinoMocks et Moq sont à la fois moqueur cadres.
Maintenant, les deux n'ont rien à voir les uns avec les autres. J'ai vraiment eu du mal à comprendre à la fois alors voici je vais essayer d'expliquer.
L'Injection de dépendance: la mise en oeuvre (permet de l'appeler) de l'Inversion de Contrôle. Vous ne confondez pas les deux. Vous prenez le contrôle de la création d'un objet de votre code. Dépendances, comme, disons, un IRepository ne serait pas créée par vos classes/code, mais au lieu injecté par quelqu'un d'autre, une infrastructure d'injection de dépendance.
Disons que vous avez
interface IUserRepository
{
string GetUserName(int id);//one method for simplicity
}
Maintenant, vous avez une réelle mise en œuvre:
class MyUserRepo : IUserRepository
{
string GetUserName(int id)
{
//grab your username from your data base here.
}
}
Maintenant tous sur la place, vous aurez:
IUserRepository repo = new MyUserRepo();//this is bad!!
Pourquoi? Demandez-vous pourquoi vous avez fait une interface en premier lieu? De sorte que vous pouvez composer avec le changement. Eh bien maintenant, lorsque vous avez besoin de changer votre référentiel à autre chose. Vous devez remplacer toutes les lignes qui ont new MyUserRepo().
Une méthode simple est d'utilisateur une méthode de fabrique, qui est une autre forme de la COI.
class RepoFactory
{
public static IUserRepository UserRepo
{
get {return MyUserRepo();}
}
}
Et de l'utiliser comme ceci:
IUserRepository rep = RepoFactory.UserRepo;
Maintenant, quand vous avez à changer votre dépôt, vous devez changer uniquement votre usine. L'injection de dépendance prend au prochain niveau, en fait tout le travail. Vous n'avez pas besoin de modifier le code à tous (ou peut-être un peu de déclarations).
IUserRepository repo;
//this magically gets the right instance based on some config somewhere.
Un Moqueur Cadre : Garçon, c'était comme la science de fusée pour moi. Mais Steven Sandersons livre a eu une brillante explication simple.
On continue avec l' IUserRepository.
Maintenant, il faut tester certains compliqué UI/Authentification de tout ce qui dépend IUserRepository.
class UserDisplay : UserControl
{
UserDisplay(IUserRepository repo)
{//display the username or something here..
}
}
Maintenant, dans votre test, lorsque vous effectuez IUserRepository d'une instance d' MyUserRepo. Si quelque chose va mal, vous ne savez pas ce qui s'est passé! Était-ce votre de contrôle de l'utilisateur ou de votre connexion de base de données?
Vous voulez faire le test plus déterministes, comme quelqu'un l'a dit.
Donc, vous faites un faux utilisateur du référentiel.
class FakeUserRepo : IUserRepository
{
public string GetUserName(int id)
{
return "FakeUser";
}
}
Alors maintenant, quand vous passez ce faux repo. Si vous êtes le test échoue, vous SAVEZ, c'était quelque chose d'autre, pas la base de données.
Mon exemple était simple, mais si ses un grand nombre d'Interfaces. Vous aurez besoin d'écrire beaucoup de faux code, c'est beaucoup de code de ballonnements!
Ainsi, vous pouvez utiliser un moqueur cadre d'écrire moins de code ici.
Moq utilise une interface fluide et très agréable. À l'aide de Moq devrait ressembler à ceci:
var fakeUserRepo = new Mock<IUserRepository>();
fakeUserRepo.Setup(f => f.GetUserName(It.IsAny<int>)).Returns("FakeUser");
//does the same thing as the class declaration
fakeUserRepo.Object;//this returns fake object of type IUserRepository
La création de faux objets devient beaucoup plus facile =)
Maintenant, je l'espère, de voir comment vous pouvez l'utiliser à votre avantage. Vous pouvez créer votre faux objets avec un moqueur cadre, puis utiliser l'injection de dépendance pour raccorder le droit d'objets au bon moment.
Pour la plus petite de mes applications Silverlight-je utiliser MEF (Intégré dans .Net4) pour l'Injection de Dépendances. Et puis j'ai peu d' #Ifdef sur les déclarations pour les classes d' Export (ou de l'exposer) Basé sur un #define symbole. Donc, je viens de changer un #define et je peux passer mon application à l'aide de faux classes ici et là.
Vraiment de l'Espoir qui a été utile.
RichardW1001
Points
1594
Ninject est une injection de dépendances/inversion de contrôle de l'outil. Vous utilisez cette fonctionnalité pour gérer les dépendances entre les classes.
L'exemple classique est que si vous avez quelque chose comme un service ou d'un référentiel de données. Au lieu d'utiliser un béton de classe tout au long de l'application, vous pouvez demander au noyau Ninject pour vous obtenir une instance de l'interface. Cela signifie que vous pouvez faire de multiples béton des classes qui implémentent l'interface, et les échanger dans un seul endroit. Ceci est extrêmement utile pour les tests, mais va bien au-delà. Beaucoup de Cio conteneurs, Ninject ne fait pas exception, permettra également de faire des choses comme gérer le cycle de vie de l'instance et une foule d'autres choses. Dites-le si vous voulez utiliser 1 dépôt par le web demande, ou d'une seule instance d'une classe, c'est le genre de chose Ninject peut prendre en charge pour vous très proprement.
Moq, RhinoMocks etc sont habitées par les cadres, ils génèrent de faux classes pour vous affirmer que d'autres parties de l'application d'interagir avec eux de manière correcte. Ce sont vraiment utiles que pour les tests, car la moqué objets ne fournit pas de fonctionnalité au-delà de rendre des comptes sur la façon dont ils ont été consultés.
Vous pourriez également vouloir vérifier StructureMap - structuremap.net/structuremap - ils ont quelques bons articles décrivant la structure, et aussi Rob Conery n'épisodes sur Cio - http://www.asp.net/mvc/videos/aspnet-mvc-storefront-part-13-dependency-injection - et Moqueur - http://www.asp.net/mvc/videos/aspnet-mvc-storefront-part-12-mocking - qui sont une bonne montre et décrivent bien mieux que je peux ce que les uns sont sur le.
