Il existe de nombreux modèles de conception utilisés, mais il en existe quelques-uns évidents:
Proxy - largement utilisé dans AOP et à distance .
Singleton - les beans définis dans les fichiers de configuration de printemps sont des singletons par défaut.
Méthode de modèle - largement utilisée pour traiter le code répété standard (tel que la fermeture des connexions proprement, etc.). Par exemple JdbcTemplate , JmsTemplate , JpaTemplate .
Mettre à jour les commentaires suivants: pour MVC, vous souhaiterez peut-être lire la référence MVC
Quelques modèles évidents utilisés dans MVC:
Contrôleur de vue modèle :-). L'avantage de Spring MVC est que vos contrôleurs sont des POJO et non des servlets. Cela facilite les tests des contrôleurs. Une chose à noter est que le contrôleur doit uniquement renvoyer un nom de vue logique et que la sélection de vue est laissée à un ViewResolver distinct . Cela facilite la réutilisation des contrôleurs pour différentes technologies d'affichage.
View Helper - Spring possède un certain nombre de balises JSP personnalisées et de macros de vitesse pour aider à séparer le code de la présentation dans les vues.
Merci, Quels sont les modèles de conception utilisés dans le module Spring MVC?
Tony
10
Je ne pense pas que Spring implémente le singleton pour les haricots. Notez qu'un bean à portée singleton aura une seule instance par contexte d'application . Donc, si votre application a deux contextes Spring, ils chargent un même bean singleton Fooet vous récupérez l'instance de Foopar contexte, vous obtiendrez deux références d'objet différentes. Au lieu de cela, le modèle de conception appliqué ici est poids mouche
Luiggi Mendoza
@Luiggi Mendoza tu veux dire que le printemps n'a pas d'objets singleton? Veuillez m'expliquer avec quelques éclaircissements.
Kumaresan Perumal
1
@KumaresanPerumal il y a une différence significative entre le modèle Singleton et l'instance singleton (notez le S majuscule / minuscule). Le modèle Singleton consiste à maintenir une seule instance de l'objet dans toute l'application. Ce que fait Spring lors de la détection d'un bean singleton est de créer une seule instance par contexte d'application . Le contexte d'application est le composant principal de Spring et sert à déléguer la création et la récupération d'objets. Le bean singleton n'est créé qu'une seule fois par contexte d'application.
Luiggi Mendoza
Liens vers le contrôleur de vue modèle, le contrôleur frontal et la vue aidée vers oracle.com/technetwork/java/index.html . Pourriez-vous s'il vous plaît mettre à jour la réponse avec un lien fonctionnel?
SpringLearner
12
Et bien sûr l'injection de dépendances, ou IoC (inversion de contrôle), qui est au cœur de tout le contenu de BeanFactory / ApplicationContext.
La chose DI est en fait une sorte de modèle de stratégie. Chaque fois que vous souhaitez que la logique / l'implémentation soit échangeable, vous trouvez généralement une interface et une méthode de définition appropriée sur la classe hôte pour câbler votre implémentation personnalisée de cette interface.
Réponse du Maître lui-même. @Oliver pourriez-vous énoncer plus de modèles ici?
Gaurav
7
Spring est une collection de modèles d'API des meilleures pratiques, vous pouvez en rédiger une liste de courses aussi longtemps que votre bras. La façon dont l'API est conçue vous encourage (mais ne vous oblige pas) à suivre ces modèles, et la moitié du temps vous les suivez sans savoir que vous le faites.
Modèle de localisateur de service - ServiceLocatorFactoryBean conserve les informations de tous les beans dans le contexte. Lorsque le code client demande un service (bean) en utilisant name, il localise simplement ce bean dans le contexte et le renvoie. Le code client n'a pas besoin d'écrire du code lié au ressort pour localiser un bean.
Patter de méthode d'usine: BeanFactory pour créer une instance d'un objet Singleton: le type d'instance peut être un singleton pour un contexte Prototype: le type d'instance peut être un prototype. Modèle de générateur: vous pouvez également définir une méthode dans une classe qui sera chargée de créer une instance complexe.
Le conteneur Spring génère des objets bean en fonction de la portée du bean (singleton, prototype etc.). Cela ressemble donc à l'implémentation du modèle Abstract Factory . Dans l'implémentation interne de Spring, je suis sûr que chaque portée doit être liée à une classe de type d'usine spécifique.
Réponses:
Il existe de nombreux modèles de conception utilisés, mais il en existe quelques-uns évidents:
Proxy - largement utilisé dans AOP et à distance .
Singleton - les beans définis dans les fichiers de configuration de printemps sont des singletons par défaut.
Méthode de modèle - largement utilisée pour traiter le code répété standard (tel que la fermeture des connexions proprement, etc.). Par exemple JdbcTemplate , JmsTemplate , JpaTemplate .
Mettre à jour les commentaires suivants: pour MVC, vous souhaiterez peut-être lire la référence MVC
Quelques modèles évidents utilisés dans MVC:
Contrôleur de vue modèle :-). L'avantage de Spring MVC est que vos contrôleurs sont des POJO et non des servlets. Cela facilite les tests des contrôleurs. Une chose à noter est que le contrôleur doit uniquement renvoyer un nom de vue logique et que la sélection de vue est laissée à un ViewResolver distinct . Cela facilite la réutilisation des contrôleurs pour différentes technologies d'affichage.
Contrôleur avant . Spring fournit DispatcherServlet pour garantir qu'une demande entrante est envoyée à vos contrôleurs.
View Helper - Spring possède un certain nombre de balises JSP personnalisées et de macros de vitesse pour aider à séparer le code de la présentation dans les vues.
la source
Fooet vous récupérez l'instance deFoopar contexte, vous obtiendrez deux références d'objet différentes. Au lieu de cela, le modèle de conception appliqué ici est poids moucheEt bien sûr l'injection de dépendances, ou IoC (inversion de contrôle), qui est au cœur de tout le contenu de BeanFactory / ApplicationContext.
la source
La chose DI est en fait une sorte de modèle de stratégie. Chaque fois que vous souhaitez que la logique / l'implémentation soit échangeable, vous trouvez généralement une interface et une méthode de définition appropriée sur la classe hôte pour câbler votre implémentation personnalisée de cette interface.
la source
Spring est une collection de modèles d'API des meilleures pratiques, vous pouvez en rédiger une liste de courses aussi longtemps que votre bras. La façon dont l'API est conçue vous encourage (mais ne vous oblige pas) à suivre ces modèles, et la moitié du temps vous les suivez sans savoir que vous le faites.
la source
Modèle de localisateur de service - ServiceLocatorFactoryBean conserve les informations de tous les beans dans le contexte. Lorsque le code client demande un service (bean) en utilisant name, il localise simplement ce bean dans le contexte et le renvoie. Le code client n'a pas besoin d'écrire du code lié au ressort pour localiser un bean.
la source
Observer-Observable: il est utilisé dans le mécanisme d'événement d'ApplicationContext
la source
Le modèle d'usine est également utilisé pour charger des beans via le contexte BeanFactory et Application.
la source
Patter de méthode d'usine: BeanFactory pour créer une instance d'un objet Singleton: le type d'instance peut être un singleton pour un contexte Prototype: le type d'instance peut être un prototype. Modèle de générateur: vous pouvez également définir une méthode dans une classe qui sera chargée de créer une instance complexe.
la source
Le conteneur Spring génère des objets bean en fonction de la portée du bean (singleton, prototype etc.). Cela ressemble donc à l'implémentation du modèle Abstract Factory . Dans l'implémentation interne de Spring, je suis sûr que chaque portée doit être liée à une classe de type d'usine spécifique.
la source