Je sais que cette question est vague, mais je vais essayer de me faire claire.
Je commence un projet Java impliquant une interface graphique swing. Je souhaite suivre le modèle MVC et utiliser une aide d'un cadre pour organiser l'architecture du projet. Je pensais utiliser Griffon , bien que je suppose que les autres puissent faire le tour.
Alors, est-ce une bonne idée d'utiliser un cadre en termes de:
Efficacité de la programmation: Bien sûr, il sera amélioré ... la plupart du temps . Plus précisément, que si le projet est un petit? Ou un grand? Et si je suis déjà très familier avec Java et Swing? Et si je ne suis pas? Et si le projet doit être maintenu par une personne qui ne sait rien sur le cadre que j'ai utilisé?
Valeur d'apprentissage: Est-ce que je vais simplement "apprendre à utiliser le cadre", au lieu d'en apprendre davantage sur Java et de balancer dans un environnement différent?
Valeur professionnelle: les entreprises préféreraient-elles un développeur qui connaît des cadres "plus" (même s'ils ne sont peut-être pas ceux qu'ils ont l'intention d'utiliser) à un développeur qui connaît mieux l'approche "traditionnelle"?
J'ai trouvé peu d'informations ailleurs, ce qui est surprenant, compte tenu de la taille de cette question. Cela pourrait sembler trivial, mais je m'interroge réellement à ce sujet.
4 Réponses :
La mise en œuvre du motif MVC pour un environnement doit être facile si vous le comprenez. D'abord une note sur celle-ci: http: //fr.wikipedia .org / wiki / modèle% E2% 80% 93View% E2% 80% 93Controller
venant maintenant à votre environnement, qui est basé sur la balançoire, vous pouvez implémenter votre code en divisant le modèle-View-contrôleur. Les vues sont vos classes de swing où êtes-vous en train de créer l'interface utilisateur. Dans de telles classes, vous devez simplement capturer les actions de l'utilisateur via différents auditeurs, mais ne doit pas mettre en œuvre une logique commerciale.Controller doit faire la logique commerciale et utiliser le modèle à tout moment.
Par exemple, vous créez une interface graphique swing pour la connexion. Créez une classe LOGINVIEW où vous allez créer le cadre, les champs de texte, les boutons, etc. et joignez également les auditeurs à différents contrôles comme vous le souhaitez. Maintenant, chaque fois qu'un utilisateur soumet le login, vous devez appeler le contrôleur pour effectuer la validation des informations d'identification. Les informations d'identification peuvent être stockées dans un DB, qui doivent être chargées et stockées dans le modèle (DAOS). Le contrôleur doit obtenir l'entrée de l'utilisateur à partir de la vue, corriger les informations d'identification du modèle et la logique de comparaison doit être implémentée dans le contrôleur.
espérons que cela aide!
J'évaluais Griffon comme cadre. J'ai eu l'impression que ce projet meurait lentement. IMHO GROOVY n'est plus un courant dominant (je me demande si cela était un grand public?). Maintenant, tout le monde fonde Scala.
Retour à votre question:
Merci pour cette réponse pratique.
J'ai peur que Scala soit plus de battage médiatique que toute autre chose ces jours-ci. Quoi qu'il en soit, Griffon soutient Scala aussi (bientôt Scalafx), de sorte qu'il est aussi grand public que Scala peut être (par votre propre compte).
@Ammiray à partir du plug-in Docs: IT (SCALA) sera compilé avant toute sources disponible sur GRIFFON-APP ou SRC / MAIN, ce qui signifie que vous ne pouvez en faire référence à aucune de ces sources de votre code SCALAA. Et oui, je ne voulais pas blesser quelqu'un de sentiment;) J'ai moi-même un projet sur Grails.
@aalmiray une dernière chose. Le plugin Scala pour Griffon a été mis à jour pour la dernière fois en janvier 2011.
@Funtik La dernière version du plugin Scala a été publiée le 04/10/2013 en fait artefacts.griffon-framework.org/plugin/scala/roélases Vous avez peut-être vu une page précédente griffon.codehaus.org/scala+plugin celui-là n'est plus actif
@aalmiray, qu'en est-il de mon premier commentaire? Les sources compilées peuvent-elles être partagées?
@Funtik code peut être partagé s'il est placé sous src / scala-communes et src / communes , estime qu'il n'y a pas de compilateur joint capable de compiler le code Scala et Groovy dans un seul étape. Vous pouvez définir des interfaces / traits dans ces répertoires, puis le code dans griffon-app ou même src / principal se référer à ces définitions; Le code sous src / scala devrait être capable de voir toutes ces classes aussi.
Comme nous le savons, Griffon est basé sur Groovy et Groovy a un beau style Java , vous éviterez probablement beaucoup de ligne de code, mais nous devons toujours envisager certains aspects tels que la connaissance et le calendrier. < / p>
Alors, envisagez d'utiliser ce que vous savez et étudiez de nouvelles choses à un autre projet.
Évitez de plonger dans l'obscurité sans votre lampe de poche.
Bien sûr, je suis biaisé quand il s'agit de Griffon, mais je vais essayer d'être aussi objectif que possible:
Mais à la fin il n'y a qu'une seule opinion qui compte: le vôtre. Je vous recommanderais de passer quelques heures avec Griffon, si vous ne voyez pas la valeur ajoutée par là par là ... J'ai bien peur que nous devrions travailler plus fort pour le rendre meilleur.
acclamations
Merci ! Cependant, ma question était réellement destinée aux cadres en général - je pense que Griffon serait un bon choix si je décide d'en utiliser un. Je suis débutant à l'écriture de Guis écrit, et je trouve la création d'une application de swing à partir de zéro inutilement douloureuse, en considérant que je ne suis que des normes suivantes. Je veux toujours écrire de la nature Java depuis que je voudrais l'apprendre. J'ai donc pensé qu'un cadre fournirait au moins l'architecture de départ et éventuellement plus. C'est pourquoi.