Vous n'êtes pas identifié(e).
Pages : 1
Hello world!
Je post rarement par ici mais pour le coup j'aimerais connaitre votre façon de coder.
Le MVC
Ayant travaillé avec des framworks comme RubyOnRails, Laravel et Django, je connais quelques design pattern et à l'université on insiste beaucoup sur le MVC.
Décomposer le code en MVC est devenu presque naturel pour moi avec le temps mais au début j'avais énormément de difficulté à adapter ma façon de conceptualiser, de penser un code pour résoudre un problème.
Pourtant je me dis que par moment, ce pattern n'est pas très adapté...
On m'a demandé de faire un parser qui analyse les fonctions faillibles d'un code source en C. J'aime bien quand ça parle de sécu en C. J'ai respecté bêtement et méchamment le modèle MVC. Résultat, pour le moment le code est lisible mais il y a énormément de lignes pour au final pas grand chose..
Moi qui avait pour philosophie d'écrire le code le plus court possible, tout en privilégiant la lisibilité du code.
Interaction avec une base de données et l'orientée objet
Autre chose qui m'intéresse. Comment programmez-vous l'interaction entre un programme (ruby, java, c++, ect) et une base de données SQL. (postgresql, sqlite, peu importe)
J'avais appris qu'il est plus intéressant de représenter chaque table (ou presque) par une classe dont les atttributs représentent chacun une colonne. Les méthodes ayant pour but d'effectuer des requêtes.
Le fait est que dans le cas d'une jointure entre plusieurs tables, on serait tenté de faire la jointure en SQL et de représenter la table résultante par une classe. Mais un prof me l'avait déconseillé car apparemment cela rendrait les tests unitaires plus compliqués à mettre en place. Qu'en pensez-vous ?
Votre avis m'intéresse. Je sais qu'on a des développeurs dans le coin et je pense que partager sa façon de programmer pourrait me permettre de m'améliorer.
Sur ce,
Hors ligne
Je peux te répondre pour la partie POO.
Par interaction avec la base de donnée, tu mentionnes indirectement le pattern DAO (une classe par table et tu travailles avec des tableaux/listes et tu gères au maximum tes requêtes de manière programmatique, interagissant le moins possible avec la DB) mais ca dépend du projet, si tu as beaucoup de tables a gérer qui elles-mêmes contiennent beaucoup de champs, ca peut devenir problématique de créer des myriades de classes pour chaque table.
J'ai appris que pour les connexions (de formations et avec expérience) pour te connecter a une DB, tu fais un singleton, pour qu'il n'y ait qu'une seule instance se connectant à la base, c'est plus performant.
Concernant les jointures et les SELECT un peu complexes, utilises des VIEW et des procédures stoquées que tu appelles avec un CALL. Non seulement les VIEW te permettent de filtrer les champs qu'elle contient mais tu peux CREATE VIEW AS SELECT avec des jointures dedans.
Pour java, Hibernate est une bonne solution, ca t'évites de "recréer la roue" en faisant des DAO.
PS: Si jamais tu décides d'upload ta DB sur un hébergement, renseignes toi sur l'hébergement en question. Les permissions pour des connexions en ODBC depuis un client MySQL (ou un logiciel que tu pourrais avoir développé) devenant une denrée rare, pour des raisons évidentes de sécurité.
Hors ligne
je code avec les doigts, de pieds parfois ^^
https://www.youtube.com/watch?v=aeePeVUW6-k
Désolé...
Plus sérieusement, depuis la fin de mes études je ne touche plus au PHP/JS, au C#, au Java... Mon cœur va vers des langages scripts, majoritairement Lisp (par plaisir), script shell (pour mon PC perso et le boulot), Powershell (pour le boulot), Ruby (j'aime de moins en moins).
D'une autre façon, SQL et T-SQL au boulot également.
Au final, vive l'algorithmie !
Hors ligne
idem, j'ai lâché le php, java, et autre. Je suis constamment sur le scripting shell , regex , python(version3) et sa suffit largement pour coder pour un optimiser un systeme ou du web.
"Les paroles peuvent être plus tranchantes qu'un sabre affûté" écrit par Omar Khayam poète perse.
Hors ligne
Merci pour vos retours.
Effectivement le DAO correspond à ce qu'on m'avait appris. Le singleton est pas mal ! Dans mon parser, les classes qui héritent de la classe Model (et qui sont donc aussi des models) doivent utiliser le constructeur de la classe parente pour se connecter à la bdd. Cela multiplie les connexions. Bref je vais revoir la conception de mon programme.
Concernant le java, ce n'est pas mon langage favori je préfère de loin le ruby mais honnêtement je ne pense pas avoir suffisamment d'expérience pour critiquer ce langage.
Pas mal la ref à l'ermite moderne
Hors ligne
Pages : 1