Discussion :

[hamzawhy]

Bonjour,
je vais travailler une application de comptabilité pour mon projet de fin d'études.Après une lecture de plusieurs articles,j'ai choisis symfony2 pour tout traitement base de données(sélection,modification,insertion) (partie backend) et AngularJS pour le frontend,chaque projet est à part,que pensez vous?
merci pour l'aide

[Invité]

Salut

POur le CRUD, moi je te conseille de ne pas utiliser Symphony, y'a pas besoin...

Tu crées toi même ton CRUD(lecture,enregistrement,updates) vite fait en PHP, et tu te concentres sur angular. (Angular c'est l'avenir...)

[tdutrion]

POur le CRUD, moi je te conseille de ne pas utiliser Symphony, y'a pas besoin...

Euh... c'est quand même pratique d'utiliser un framework pour avoir un MVC build-in (enfin si on considère un endpoint comme une vue ici), avoir un container d'injection de dépendance prêt à utiliser, juste à paramétrer et tout... Symfony fournis aussi Doctrine 2 par défaut, ce qui est pratique pour faire du CRUD. Pour moi c'est un bon choix, particulièrement quand tu regardes le nombre de bundles disponibles et la communauté. (Symfony d'ailleurs, pas Symphony...)

Tu crées toi même ton CRUD(lecture,enregistrement,updates) vite fait en PHP, et tu te concentres sur angular. (Angular c'est l'avenir...)

Je ne critique pas le fait qu'Angular soit l'avenir (bien que discutable, d'ailleurs Angular 2 ne ressemblera pas au 1er), par contre je vois pas le rapport, étant donné qu'Angular est front et PHP back...


hamzawhy: regarde aussi du côté de FOSRestBundle pour ton API.

[bretus]

Tu crées toi même ton CRUD(lecture,enregistrement,updates) vite fait en PHP, et tu te concentres sur angular. (Angular c'est l'avenir...)

Oui, oui... et surtout, tu ne valides rien en provenance du client : Tu fais confiance aux contrôles en JavaScript! La base de données a de l'avenir avec ça...

On va faire simple : Symfony2 permet de faire des formulaires avec des mécanismes de validation côté serveur qui assureront l'intégrité des données. Il t'amènera un MVC qui te permettra de gérer proprement tes appels entre les différentes pages et de mettre en facteur le contenu commun à ces pages.

A mon goût, Angular et Symfony2 font un peu doublon (routing & templating). Un couplage Symfony2 + Bootstrap est largement suffisant dans bien des cas.

[tdutrion]

A mon goût, Angular et Symfony2 font un peu doublon (routing & templating). Un couplage Symfony2 + Bootstrap est largement suffisant dans bien des cas.

Il y a quand même un avantage à séparer completement le front et le back dans des applications independantes, c'est que tu as juste à passer ton front dans cordova pour generer tes mobile apps...

[bretus]

Il y a quand même un avantage à séparer completement le front et le back dans des applications independantes, c'est que tu as juste à passer ton front dans cordova pour generer tes mobile apps...

On parle quand même d'une application de comptabilité... Il faudrait d'ailleurs peut-être commencer par se poser les bonnes questions avant de savoir comment on procède :

- Quels sont les rôles des utilisateurs? Est-ce qu'ils sont tous authentifiés?
- Quels sont les grandes fonctionnalités?

Après, on passe aux questions qui permettent de tracer les grandes lignes de l'architecture (il n'y a pas de recette miracle valable pour toutes les applications) :
- Est-ce qu'on a le moindre intérêt à faire maintenant ou plus tard une application mobile ou un site adapté aux petits écrans?
- Est-ce qu'on doit exposer des données pour d'autres applications? API/Flux nécessaires ou non?
- Est-ce qu'on doit effectuer des contrôles complexes sur les données saisies? En bref, est-ce qu'on a besoin de sortir l'artillerie lourde pour valider les formulaires côté serveur?
- Est-ce qu'on a un modèle de données complexes? Est-ce qu'il est susceptible d'évoluer? En bref, est-ce qu'un ORM va nous apporter quelques choses.
- Sachant qu'on doit valider les données côté serveur, est-ce qu'on a intérêt à les valider côté client?
- Est-ce qu'on veut être bien référencé (je ne sais pas ce que ça donne avec le routing d'angular à base d'anchor)?


Du reste, la conception d'une application mobile et d'un site adapté aux mobiles n'a pas d'autres raisons que la facilité d'être la même :
- Tu as beau avoir le code HTML et JS qui charge hors ligne : Si tu ne fais en sorte de stocker les données côtés clients, l'application ne charge pas. Un InAppBrowser doit donc faire autant l'affaire si on veut juste apparaitre sur un store non?
- Tu n'organises pas tes fonctionnalités de la même façons quand tu utilises vraiment le mobile. Le enchainement vont être différent quand on utilise les photo, la position de l'utilisateur, la mémoire du mobile...

=> Autant faire des API et composants JS/CSS propres pour pouvoir développer à moindre coût une application dédiée aux mobiles (utiliser vraiment cordava : la possibilité de prendre des photos, d'utiliser le GPS, de stocker, etc.)