Interroger une base de données depuis javascript

Bonjour,

Pouvez-vous me dire si ça vous semble réalisable ?

Ce que j'ai aujourd'hui :

Je développe une application Web .NET qui utilise majoritairement le <canvas> (html5) pour sa partie graphique.

La base de données est en SQL Server et l'application Web est du ASP.NET Framework en mode 'Single Page Application'.

Il y a donc qu'une seule page, et les données sont récupérés par des appels Javascripts qui interrogent des WebApi... qui eux-même utilisent Entity Framework... qui utilise ma base de données.

Jusqu'ici, je suis compréhensible ?

En schéma ça donnerait ça :
Pièce jointe 318679

Aujourd'hui, j'ai autant de WebAPI que de tables principales, et c'est un peu lourd je trouve.
Dès que je créé une table, j'actualise le modèle objet Entity (là c'est automatique, pas de souci), puis je suis obligé de créer une nouvelle WebAPI, puis des nouveaux Appels Ajax, puis mettre à jour mes objets javascripts.

Alors voici l'idée :
Pourrais-je développer une Web Api 'générique' qui accepte tout type de requête (update, select, delete) et sur toutes les tables disponibles ?
L'idée est que je puisse écrire ma requête directement dans le code javascript (selon une norme à définir) pour enlever toute l'intelligence des WebAPI (... et la nécessité de les maintenir).
Mes WebAPI sont déjà protégés pour ne pouvoir être utilisé que par l'application, et je n'ai que faire que mon code soit lisible par autrui.

Je suis intéressé par toutes vos remarques,

Cordialement,
Stève

niveau sécurité tu n'as pas de contraintes ?

Pas de contrainte de sécurité, uniquement de productivité pour l'instant.
Ce n'est pas une application dédiée à être ouverte sur le web.

parce que faire passer une requete à l'api ca permettrait de faire passer n'importe quoi genre select * from sys.tables et tout le reste par la suite pour tout pirater :D

après avec entity framework je ne sais pas trop comment tu peux t'en sortir, mais avec des requetes SQL direct c'est en effet faisable
par contre tu perds l'avantage d'EF qui est d'avoir du code généré par table et rempli automatiquement, et faire tes poco toi même ca sera plus chiants que te taper les requetes linq EF et d'écrire un point d'entrée API je pense

sinon il faudrait faire abstraction de l'objet mais transmettre des choses plus simples, genre un tableau de nom_colonne/valeur
(le sql datareader permet de récupérer les noms de colonnes dynamiquement)
si tu veux camoufler un peu la structure de la base, tu peux aussi faire des vues, tu transmets alors le nom de la vue, ca a aussi l'avantage que tu peux changer la vue sans modifier le code JS

Merci de ta réponse Pol63

En effet, le principe des vues me permet d'augmenter la sécurité.

Pour éviter les "select * from sys.tables", il me suffit de gérer les droits proprement au niveau du compte de service IIS qui accède à la base de données.

Sinon, mes recherches m'ont menés à étudier "Dynamic Linq" pour générer des requêtes LINQ dynamiquements mais c'est plus complexe que : <string> génère <requête linq>
J'hésite à introduire cette nouvelle couche de complexité.

Je pourrais également passer par un tableau Excel : X feuilles pour X tables, avec des jeux de données de test ; et une "petite" macro qui génère :
1) les scripts SQL de création des tables et des contraintes associés (un maximum de contrainte, ce serait les seuls contrôles côté serveur)
2) le remplissage de ces tables avec les données de test
3) la génération des WebPI avec des requêtes linq "standards" : get / post / put / delete
avec l'idée de rendre variable uniquement les colonnes retournées, et les conditions avec une transco de ce type : A et (B ou C) = [0,[A,true],[1,[B,true],[C,true]]
4) la génération des appels Ajax, avec les contraintes associés côté javascript

Avec ça, j'ai du clic-bouton pour générer une architecture cohérente et modulaire.
Même si ça peut paraître compliqué, ça reste de la manipulation de chaîne, avec des replaces, et des boucles.

Je continue un peu avec mon schéma actuel avant de me lancer là dedans.

Bonjour ,
Regardes ODATA ca pourrait être une piste pour toi . Sinon regardes plutôt des templates déjà existant pour ce genre d application à ce niveau c est des soucis d architecture que t as ce qui est normal vu que ton appli grossi .