Je suis nouveau au printemps MVC, j'ai téléchargé un petit projet MVC Spring. Le projet exécute une amende, mais ces interfaces et classes de projet sont utilisées.
comme et p>
public class EmployeeServiceImpl implements EmployeeService {
@Autowired
private EmployeeDao employeeDao;
@Transactional(propagation = Propagation.REQUIRED, readOnly = false)
public void addEmployee(Employee employee) {
employeeDao.addEmployee(employee);
}
public List listEmployeess() {
return employeeDao.listEmployeess();
}
public Employee getEmployee(int empid) {
return employeeDao.getEmployee(empid);
}
public void deleteEmployee(Employee employee) {
employeeDao.deleteEmployee(employee);
}
}
5 Réponses :
Les interfaces sont toujours une bonne pratique pour le découplage, mais aussi, lorsque vous parlez de printemps, il existe plusieurs fonctionnalités que vous pouvez utiliser avec des interfaces plutôt que des classes en béton.
Un grand avantage est le proxy, le ressort AOP.
Vous pouvez trouver plus d'informations ici: http://docs.spring.io/spring/docs/3.0.x/spring-Framework-reference/html/aop.html
Il y a d'autres avantages, tels que le post-traitement et des choses comme ça, mais je pense que vous aurez une lecture intéressante sur le Spring AOP.
Vous pouvez également ajouter un AOP sans utiliser des interfaces, il existe d'autres façons.
Il est recommandé d'écrire du code contre des interfaces plutôt des implémentations spécifiques.
De cette façon, le code du client ne connaît pas les implémentations spécifiques mais connaît uniquement le contrat.
Concernant le printemps, vous devez généralement utiliser des interfaces car le ressort doit souvent créer des proxy Java et cela ne peut être effectué que pour les classes qui implémentent des interfaces.
Ce n'est pas vrai. Le printemps peut également créer des proxies de classe également, ou utiliser AspectJ avec le tissage de charge pour appliquer un AOP.
@ M.Deinum Je sais que AspectJ peut être utilisé pour créer des proxies, j'ai écrit cette réponse "simple" en fonction du niveau de la question.
Il n'a pas grand-chose. Pour faire avec le printemps ou le mvc.it est une bonne pratique pour concevoir des interfaces, de sorte que la mise en œuvre puisse être facilement changements. Il fournit un couplage lâche et si vous utilisez le ressort, vous pouvez modifier la mise en œuvre. En cas de besoin.
En outre, il aide pendant les tests avec JUnit. Vous pouvez facilement se moquer de votre DAO.
Quelques principes qui font partie du Solid acronyme pour OO Conception s'applique à ceci:
t code> sans affecter le résultat du problème. Par exemple, si vous appelez une méthode qui renvoie une liste code> et que l'implémentation sous-jacente bascule du renvoi d'un tableau arraylist code> à un linkedlist code >, votre programme devrait toujours fonctionner de la même manière. Fondamentalement, vous devez concevoir vos classes afin que les dépendances des clients puissent être substituées par des sous-classes sans que le client connaisse le changement. Voici un court extrait de la page wiki: li>
ol>
La substituabilité est un principe de la programmation orientée objet. Ce
déclare que, dans un programme informatique, si S est un sous-type de T, puis
Les objets de type T peuvent être remplacés par des objets de type S (c'est-à-dire
Les objets de type S peuvent substituer des objets de type T) sans altérer
aucune des propriétés souhaitables de ce programme (exactitude, tâche
effectué, etc.) p>
blockQuote>
- Principe d'inversion de dépendance - L'idée principale est que vous isolez la classe derrière une limite basée sur les abstractions dont cela dépend. De cette façon, si l'un des détails qui se trouvent derrière ces abstractions changent, la classe ne sera pas affectée. Li>
ol>
Dans la programmation orientée objet, le principe d'inversion de dépendance
Fait référence à une forme spécifique de modules logiciels de découplage. Lorsque
Suite à ce principe, les relations de dépendance conventionnelles
établi à partir de modules de réglage de stratégie de haut niveau à bas niveau,
Les modules de dépendance sont inversés (c'est-à-dire inversé), rendu ainsi
Modules de haut niveau indépendant de la mise en œuvre du module de faible niveau
des détails. Le principe indique p>
A. High-level modules should not depend on low-level modules.
Both should depend on abstractions.
B. Abstractions should not depend on details.
Details should depend on abstractions.
Printemps météo MVC ou non, il faut toujours coder à l'interface. L'interface me donne une meilleure lisibilité lorsque je veux juste voir ce que la classe fait au lieu de vous inquiéter de la manière dont elle le fait, une sorte d'API exposée au monde extérieur.
Un autre avantage est qu'il pourrait y avoir plusieurs implémentations de «Comment faire» et le ressort permet de passer facilement entre plusieurs implémentations. Par ex. Vous pourriez avoir une nouvelle mise en œuvre de EmploymentService Dites à FullTimeMosployserviceImpl, RemontemployserviceImpl. P>
MAINTENANT Si vous avez une classe client qui utilise Emunserservice: P>
<bean id="employeeManager" class="com.abc.EmployeeManager"> <property name="service" ref="fullTimeEmployee | remoteEmployee" > </bean> <bean id="fullTimeEmployee" class="com.abc.FullTimeEmployeeServiceImpl" /> <bean id="remoteEmployee" class="com.abc.RemoteEmployeeServiceImpl" />
Vous devriez programmer des interfaces afin que votre code soit utilisé pour utiliser le
Essordice . Ensuite, votreEssentiservice n'est en réalité pas si bon comme un service doit représenter des fonctions de votre système inutiles. Vous n'utilisez que comme une couche de complexité ajoutée pour cacher votre DAO.Je pense que la principale raison est l'injection de dépendance. Lisez ce message; Stackoverflow.com/Questtions/256255/spring-and-interfaces
Je sais que c'est un ancien poste mais je voulais juste faire un point, il n'y a aucune justification à l'aide des classes impliquées. Le point d'utilisation de l'interface doit avoir plus d'une implémentation (sinon, alors, plus probablement à l'avenir). Pour l'ajout de l'interface, il est inutile d'utiliser. par exemple. Vous pouvez utiliser une interface LISTService qui possède une méthode de liste (), puis vous pouvez avoir une classe employée qui peut la mettre en œuvre, mais la rédaction de l'interface employée et d'employée d'employés est inutile. Réf: lien