[AC-2013 -> ASP.NET] Architecture

Version imprimable

05/02/2015, 18h45
vduvernet

[AC-2013 -> ASP.NET] Architecture

Bonjour,

je me pose une question concernant ASP.NET (aucune expérience de dev dessus pour le moment).
J'ai un projet perso sous Access 2013 que je vais étoffer en C#.
Pour le moment, il est prévu en local, mono utilisateur.

Si demain il me prenait l'envie d'en faire une version LAN-multipostes ou via ASP.NET voir une version ASP.NET "Cloud", il y aurait sûrement des modifications à anticiper et à faire. Le tout étant de savoir lesquelles ^^.

- Est ce que l'on prévoit pour chaque élément de la table un numéro indiquant l'utilisateur qui a crée et un autre pour l'utilisateur qui a modifié l'enregistrement ? (et ce pour toutes les tables)
- Avec la version ASP.NET "cloud", si on a 2 clients qui veulent remplir leur table Article tout en étant indépendant l'un de l'autre. (On suppose que le boulanger ne veut pas voir des pneus et inversement). Ca se traduit comment techniquement ? Les 2 clients tapent dans une base commune et un champ permettant de les différencier est ajouté ? Ou bien, est ce une forme d'instance ou de clone afin que chaque client ai sa propre table ?

Merci,

Vincent
06/02/2015, 09h42
Dokho1000

Je pense pas que la question est dans le bon forum car que ce soit du asp.net ou autre le problème est le même. Tu devras déjà changer ta BDD car une base accès ne pourra pas supporter (ou difficilement) une charge d'utilisateurs simultanés. J'irais voir dans le forum sgbd...
07/02/2015, 00h44
Graffito

Citation:

Tu devras déjà changer ta BDD car une base accès ne pourra pas supporter (ou difficilement) une charge d'utilisateurs simultanés.

Même s'il a ses défauts (et quelques avantages), Access supportera aisement de 5 ou 10 utilisateurs simultanés.
07/02/2015, 16h13
DotNetMatt

Citation:

Envoyé par vduvernet

Si demain il me prenait l'envie d'en faire une version LAN-multipostes ou via ASP.NET voir une version ASP.NET "Cloud", il y aurait sûrement des modifications à anticiper et à faire. Le tout étant de savoir lesquelles ^^.

Si tu prévois déjà de partir dans le cloud alors à mon avis il vaut mieux t'orienter vers un SGBDR plus robuste qu'Access (qui rappelons-le est avant tout prévu pour des utilisateurs non IT). Tu peux regarder SQL Server Express, qui est gratuit et que tu pourras très facilement utiliser plus tard en mode cloud... Cela te permettra de pouvoir gérer les sauvegardes, etc. facilement dans le cloud, avec les outils du provider. Si tu choisis Access il faudra gérer tout cela toi-même, manuellement.

Citation:

Envoyé par vduvernet

- Est ce que l'on prévoit pour chaque élément de la table un numéro indiquant l'utilisateur qui a crée et un autre pour l'utilisateur qui a modifié l'enregistrement ? (et ce pour toutes les tables)

Si tu as besoin de savoir qui a créé/modifié ces enregistrements alors oui il faut le faire. Tu crées une table User avec une colonne Id. Ensuite dans chacune des tables tu créés une colonne CreatedByUserId et une ModifiedByUserId, puis tu places une clé étrangère qui permettra de faire le lien vers la colonne Id de la table User.

Citation:

Envoyé par vduvernet

- Avec la version ASP.NET "cloud", si on a 2 clients qui veulent remplir leur table Article tout en étant indépendant l'un de l'autre. (On suppose que le boulanger ne veut pas voir des pneus et inversement). Ca se traduit comment techniquement ? Les 2 clients tapent dans une base commune et un champ permettant de les différencier est ajouté ? Ou bien, est ce une forme d'instance ou de clone afin que chaque client ai sa propre table ?

Tu peux définir cela dans la base de données, dans une table spécifique. Par exemple en associant les Id des métiers, avec les Ids des objets (pneu, etc.). Tu pourras ainsi savoir qui est autorisé à voir ou ne pas voir quoi. Tu peux aussi le faire dans ton code dans la couche métier (business). En fonction des cas (par exemple si tu as besoin de faire du reporting sur ces info derrière...) il peut être bénéfique de faire cela dans la base de données plutôt que dans ton application...
09/02/2015, 09h53
Dokho1000

Citation:

Envoyé par Graffito

Même s'il a ses défauts (et quelques avantages), Access supportera aisement de 5 ou 10 utilisateurs simultanés.

Je suis encore sceptique sur le aisément, c'est en supposant que la gestion des connexions soit très bien pensée car sinon il y a un risque de laisser des sessions DB ouverte et de planté son site. (j'en ai l’expérience en reprenant au boulot un vieux cms basé sur une db access)

De mon avis, utiliser access ce n'est que pour des applis mono-user. (Passer de mono à multi en gardant un fichier access c'est faire le choix de la facilité)
09/02/2015, 21h44
nachtigal

Bonjour,
Ne fais pas des économie de bouts de chandelle, tu le payeras fort devant, aussi vaut-il mieux dès maintenant basculer sur une "vraie" base de donnée ; MS SQL Server Express toutes éditions confondues est gratuit et fait très bien ce travail.
Si tu installes d'abord "webpi", lui installera la bête avec toutes ses dépendances, sans oublier l'interface Management Studio !!
Ensuite, opte pour une une gestion des utilisateurs, ASP.NET en a une intégrée très bonne, à défaut tu peux prendre une gestion des utilisateurs embarquée dans disons SQLite qui le fait très bien.
Pour la gestion des accès, dans chaque table tu mets systématiquement CreatedBy, ModifiedBy, etc, et tu récupères le UserID qui est un Guid que tu le mets dans ces champs en création, modification, etc...
Pour ma part j'ai rajouté aussi systématiquement un champ boulean : PrivateOnly, que je mets à true par défaut lors de toute création. Ainsi pour chaque requête d'affichage, je filtre systématiquement les données par le UserID pour n'afficher que les données créées par l'utilisateur courant, en plus des autres conditions de sélection... Dans chaque fiche, un champ permet à l'utilisateur de rendre "public" son enregistrement en désélectionnant PrivateOnly.
Voilà, j'espère t'avoir mis sur la voie, sinon n'hésite pas, demande !!
nachtigal

PS. Oublie ACCESS !!