Dies ist eher eine Frage für die Praxis. Ich möchte verschiedene generische Bibliotheken wie Logging, Caching usw. anbieten. Es gibt viele Bibliotheken von Drittanbietern wie MS Enterprise Library, log4Net, NCache usw. für diese.
Ich wollte wissen, ob seine eine gute Praxis, diese direkt zu verwenden oder erstellen Wrapper über jeden Dienst und verwenden Sie eine DI, um diesen Dienst in den Code zu injizieren.
Grüße
Das ist subjektiv, hängt aber auch von der Bibliothek ab.
Zum Beispiel haben log4net oder NHibernate streng Interface-basierte API's . Es besteht keine Notwendigkeit, sie zu verpacken. Es gibt andere Bibliotheken, die Ihre Klassen schwer testbar machen, wenn Sie keine Schnittstellen dazwischen haben. Dort könnte es ratsam sein, eine saubere Schnittstelle zu schreiben.
Manchmal ist es ratsam, nur einen kleinen Teil des Codes auf APIs zugreifen zu lassen, wie zum Beispiel NHibernate oder eine GUI-Bibliothek. (Hinweis: Dies ist kein Wrapping, sondern das Erstellen Abstraktionsschichten .) Auf der anderen Seite macht es keinen Sinn, den Zugriff auf log4net-Aufrufe zu reduzieren, da diese in der gesamten Anwendung verwendet werden.
log4net ist wahrscheinlich ein gutes Beispiel dafür, dass Wrapping einfach zu viel des Guten ist. Einige Leute leiden unter "Wrappitis", einem Anti-Muster (manchmal auch als "Wolle in Baumwolle wickeln" ) und produziert einfach mehr Arbeit. Log4net hat eine so einfache API und ist in hohem Maße anpassbar, sie machten es besser als Ihr Wrapper wahrscheinlich sein wird.
Sie werden feststellen, dass Sie eine Bibliothek nicht einfach mit einem anderen Produkt umtauschen können. Auch die Aktualisierung auf neuere Versionen wird nicht einfacher, sondern Sie müssen Ihren Wrapper umsonst aktualisieren.
Die Verwendung von Wrapping-Schnittstellen macht Unit-Tests in der Tat viel einfacher, aber was ebenso wichtig ist, sie ermöglicht die Verwendung von Mocks.
Ein Beispiel, das PRISM-Framework für Silverlight und WPF definiert eine ILoggerFacade Schnittstelle mit einer einfachen Methode namens Log . Unter Verwendung dieses Konzepts definiere ich im Folgenden einen Mocked Logger (mit Moq ) in meinen Unit-Tests:
var loggerMock = new Mock<ILoggerFacade>(MockBehavior.Loose);
loggerMock.Setup(lg => lg.Log(It.IsAny<string>(), It.IsAny<Category>(), It.IsAny<Priority>()))
.Callback((string s, Category c, Priority p) => Debug.Write(string.Format("**** {0}", s)));Später können Sie die loggerMock.Object über einen Konstruktor oder eine Eigenschaft mit dem getesteten Objekt verknüpfen oder einen Dependency Injector konfigurieren, der es verwendet.
Es hört sich so an, als wollten Sie die Implementierung der Protokollierung abschließen und dann mit verschiedenen Teams teilen. Daraus ergeben sich einige Vor- und Nachteile.
Ich habe schon einmal einen Teil der Enterprise Library verpackt, und ich fand nicht, dass es einen großen Mehrwert brachte. Ich denke, Sie wären besser dran:
Dies ist eher eine subjektive Frage, aber IMO ist es eine gute Sache, jede anwendungs-/bibliotheksspezifische Nutzung in ein Servicemodell-Design zu verpacken, das gut durchdachte Schnittstellen hat, so dass Sie DI leicht verwenden können und später, wenn Sie jemals von, sagen wir, EntLib Data Application Block zu NHibernate wechseln müssen, Sie nicht Ihre gesamte Anwendung umgestalten müssen.
In der Regel erstelle ich eine "Helfer"- oder "Service"-Klasse, die statisch aufgerufen werden kann, um gemeinsame Funktionen dieser Bibliotheken zu umhüllen.
Ich weiß nicht, ob es ein großes Risiko darstellt, diese direkt zu referenzieren/aufzurufen, da es sich definitiv um ausgereifte Projekte handelt (zumindest EntLib und Log4Net), aber ein Wrapper isoliert Sie von der Verwirrung durch Versionsänderungen usw. und gibt Ihnen mehr Optionen in der Zukunft, zu relativ geringen Kosten.
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
