Diese Seite organisiert die im neuen Projekt eingeführten Methoden zur Verwaltung der Geschäftslogik. Wie strukturiere und verwende ich verwandte Klassen in der Situation, dass "Sie keinen großen DI-Container für eine Web-API wie Spring benötigen"? Ist der Fokuspunkt.
Dieses Projekt war eine einfache allgemeine Bibliothek, die Ergebnisse zurückgab, wenn ein Argument an eine einzelne Methode übergeben wurde, die zum Einstiegspunkt wurde. Ab dem Einstiegspunkt wird die Geschäftslogik definiert, die mehreren Entitäten zugeordnet ist (eine sogenannte MVC-ähnliche Architektur).
Wenn Änderungen an der Geschäftslogik vorgenommen werden, haben wir diesmal davon ausgegangen, dass sich die Anzahl der Services mit Geschäftslogik anstelle des Einstiegspunkts erhöht oder ändert.
Die Service-Layer-Klasse, auf die vom Einstiegspunkt aus verwiesen wird, ist höchstens 4 oder 5, sodass Sie eine Instanz direkt erstellen können ...
Ich habe es aus vier Perspektiven betrachtet:
Ich beschloss, einen einfachen DI-Behälter vorzubereiten. Es ist ein Bild von einer Klasse mit einer solchen Struktur zwischen Factory-Methode, Singleton und Service Locator. Die Factory-Klasse selbst sollte eine einzelne Instanz sein, und Dienste sollten von dieser einzelnen Instanz abgerufen werden.
Stellen Sie außerdem sicher, dass Aktualisierungen der Geschäftslogik nur ab Werk betroffen sind. Als Geschäftslogik hinzugefügt wurde, fragte ich mich, ob es möglich wäre, der Fabrik eine Instanziierungsmethode hinzuzufügen.
Dann generiert die vom Dienst abhängige obere Schichtklasse den Dienst ab Werk und verwendet ihn. Annotationsbasiertes DI wie dieses in Spring und Java EE scheint in diesem Projekt etwas übertrieben zu sein, daher habe ich es in diesem Projekt nicht verwendet. Als Ergebnis verschiedener Untersuchungen habe ich ein Muster namens DYDI (Do it Yourself Dependency Injection) übernommen, das für mich einfach vorzubereiten ist und für ein kompaktes Projekt wie dieses geeignet zu sein scheint.
Es besteht aus drei Klassen: einer Klasse, die Logik generiert, einer Schnittstelle / Implementierung von Logik und einem Aufrufer.
Bereiten Sie zunächst eine Factory-Klasse vor, die eine Instanz mit Logik zurückgibt.
ServiceFactory.java
public class ServiceFactory {
/**
*Fabrikspezifische Einzelinstanz.
*/
private static final ServiceFactory serviceFactory = new ServiceFactory();
private ServiceFactory() {}
public static ServiceFactory getInstance() { return serviceFactory; }
/**
*Gibt die eigentliche Logik zurück.
*/
public TargetLogic getTargetLogic() {
return new TargetLogicImpl();
}
Definieren Sie die von dieser Factory zurückgegebene Schnittstelle und Logik. Dies ist eine schnelle Möglichkeit, es je nach Anwendungsfall flexibel zu definieren.
TargetLogic.java
public interface TargetLogic {
void consume();
}
TargetLogicImpl.java
public interface TargetLogicImpl implements TargetLogic {
void consume() {
//Etwas zu verarbeiten
}
}
Schließlich werden wir die Logik nennen.
Application.java
public class Application {
private final TargetLogic targetLogic = ServiceFactory.getInstance().getTargetLogic();
}
Sie können die Logik jetzt ab Werk in der Klasse Application abrufen.
Wie ich am Anfang gelesen habe, war die Anwendung klein und die Struktur des Projekts einfach, sodass die Methode des Abhängigkeitsmanagements genau richtig war. Selbst wenn es in Zukunft eine logische Änderung gibt, scheint es, dass sie einfach organisiert werden kann, weil es ausreicht, der Fabrik eine Methode hinzuzufügen. Wann sollten Sie eine Instanz erstellen? Sollte es nicht gemacht werden? Es war ein Nebeneffekt, der mein Nachdenken vertiefte.
Wenn Ihr Projekt jedoch etwas größer ist oder mehr Ebenen hat, ist es einfacher, sich auf Bibliotheken wie Spring und Guice zu verlassen. Um ehrlich zu sein, gibt es möglicherweise mehr Projekte, die schwer zu funktionieren sind.