|
| Logique métier dans sql server |
| Débuté par Ihebc, 13 sep. 2018 20:54 - 5 réponses |
| |
| | | |
|
| |
Posté le 13 septembre 2018 - 20:54 |
Bonjour,
Je voulais avoir un retour d'expérience concernant le mariage SQL Server et windev.
Je m'explique, en tant que dba et developpeur sql server, je pense a développé un ERP ena integrant la logique métier principalement sur ma BD (pour des raisons de sécurité, portabilite et performance).
Donc toutes mes update sur la base vont passer par des procédures sql server et des triggers instead of.
L'application va lire uniquement des views, sans avoir accès sur les tables directement.
Merci par avance |
| |
| |
| | | |
|
| | |
| |
Posté le 14 septembre 2018 - 11:26 |
je ne peux qu'intervenir sur ce sujet !
A chaque fois que je tombe sur ce genre de projet c'est toujours un spaghetti immonde, des procédures qui font déclencher des triggers qui déclenchent d'autres procédures, aucune vue d'ensemble.. et j'en ai vu des dizaines impossibles à maintenir à cause des effets de bords, je modifie ici.. oh zut ca a un impact inattendu las bas, tu corriges, patatra autre impact...
Sans compter que l'on ne peut développer de architecture, pas d'objets encapsulés, même pas de variables globales...tout est éparpillé dans du code souvent redondant à coup de paramètres et variables locales, l'horreur
Faut passer à autre chose là le programmation de papy c'est fini, les procs serveur c'est bien pour faire certains jobs en batch mais pas pour y mettre une logique métier complète 
Bon Dev
Marc fastré
www.marc-fastre.be |
| |
| |
| | | |
|
| | |
| |
Posté le 14 septembre 2018 - 14:12 |
Bonjour,
+10 000 avec Marc
Lors du développement il faut avoir en tête la maintenabilité du code et ses évolutions. Mets toi à la place de quelqu'un qui doit reprendre ton code.
Si tu veux dissocier les règles métiers de l'IHM (ce qui est une bonne chose), passes par la programmation objet. Tu codes les règles métiers dans des classes et l'IHM les utilises.
Rend ton application la plus indépendante possible de la base de donnée choisie, c'est facile avec Windev. Tu n'es pas à l'abri de devoir changer un jour. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
299 messages
Popularité : +16 (16 votes) |
|
Posté le 14 septembre 2018 - 14:58 |
Rend ton application la plus indépendante possible de la base de donnée choisie,
Ca ça me fait plaisir.
Je travaille avec WinDev et je l'interface avec SQL Serveur et, plus récemment, ACCESS à cause du contexte du client.
J'ai construit une classe exploitant une liaison ODBC, je conserve des performances correctes, une stabilité parfaite et un code nickel. |
| |
| |
| | | |
|
| | |
| |
Posté le 16 septembre 2018 - 22:04 |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
26 messages |
|
Posté le 17 septembre 2018 - 09:28 |
ihebc a écrit :
J'ai lu avec attention le débat sur sur le site de développez.net, auquel je suis abonné d’ailleurs, car c'est à mon sens la meilleure source francophone pour les développeurs.
Mais si je lis attentivement les positions de chacun, je garde toujours un œil critique sur toute information (qu'elle qu'en soit l'origine d’ailleurs).
La position, très intéressante, exposée dans le débat est celle d'un spécialiste de SQLServer. Est-il objectif ?
Vous auriez pu, aisément, trouver autant d'argument pour défendre :
" la responsabilité de la logique métier dans le code et la responsabilité de la gestion du stockage à la base de données"
Je pense, personnellement, mais ça n'engage que moi, qu'il n'y a pas une bonne et une mauvaise solution (sinon tout le monde aurait adopté la même). Si votre code se limite à faire des HAjoute, HModifie et HSupprime dans une base de données alors "câbler" la logique métier à l'aide de requête SQL pourquoi pas.
Mais vous parliez d'ERP, dans votre premier message et à mon sens cela ne peut se limiter à ça.
Je comprends, et soutiens, parfaitement la position de mes collègues qui vous ont alerter sur les risques d'une telle démarche...
Votre position est celle d'un DBA, je la respecte et mieux je la comprends.
Dans une caisse à outils, il n'y a pas de bon ou de mauvais outils même s'il y a des outils mieux adaptés à certaines tâches.
Le choix dépend, souvent, du "bricoleur" qui par expérience (il le maîtrise mieux) préfère utiliser plutôt celui-ci que celui-la.
Vous demandez, dans votre premier message, un retour d'expérience, vous l'avez eu ...
Mais vous auriez posé le même message sur le forum SQLServer vous auriez une réponse complètement opposé 
Si votre choix de conception était fait, pourquoi essayer de vous rassurer en posant la question sur un forum de développeur ?
Bonne journée.
Cordialement |
| |
| |
| | | |
|
| | | | |
| | |
|