Aspnetdb & co
Djzlouk
Messages postés
70
Date d'inscription
jeudi 26 juillet 2007
Statut
Membre
Dernière intervention
20 janvier 2011
-
18 mars 2010 à 14:33
nhervagault Messages postés 6063 Date d'inscription dimanche 13 avril 2003 Statut Membre Dernière intervention 15 juillet 2011 - 18 mars 2010 à 21:54
nhervagault Messages postés 6063 Date d'inscription dimanche 13 avril 2003 Statut Membre Dernière intervention 15 juillet 2011 - 18 mars 2010 à 21:54
3 réponses
nhervagault
Messages postés
6063
Date d'inscription
dimanche 13 avril 2003
Statut
Membre
Dernière intervention
15 juillet 2011
37
18 mars 2010 à 20:48
18 mars 2010 à 20:48
Salut,
Il faut partir sur une 3ieme posibilité, mettre les champs de la base
ASPNETDB dans ta vrai base de données.
Les scripts sont disponibles dans le SDK dotnet 2.0 sont dans le repertoire
C:\Windows\Microsoft.NET\Framework\v2.0.50727
* commun
* member
* profile
* role
* ....
Il y a une autre solution c'est d'implémeter ses propres providers
mais ca demande du temps, c'est ce qui est fait par exemple si tu veux attaquer une base mysql. (le provider est disponible sur codeplex il me semble)
Bon
Il faut partir sur une 3ieme posibilité, mettre les champs de la base
ASPNETDB dans ta vrai base de données.
Les scripts sont disponibles dans le SDK dotnet 2.0 sont dans le repertoire
C:\Windows\Microsoft.NET\Framework\v2.0.50727
* commun
* member
* profile
* role
* ....
Il y a une autre solution c'est d'implémeter ses propres providers
mais ca demande du temps, c'est ce qui est fait par exemple si tu veux attaquer une base mysql. (le provider est disponible sur codeplex il me semble)
Bon
Djzlouk
Messages postés
70
Date d'inscription
jeudi 26 juillet 2007
Statut
Membre
Dernière intervention
20 janvier 2011
18 mars 2010 à 21:21
18 mars 2010 à 21:21
Bonsoir,
Merci pour la reponse, qui me va qu'à moitié :p désolé.
Deja pour pas m'embêter, je préfère créer la base ASPNETDB puis la renommer en ce que je veux, puis ajouter mes tables. (Cela permet d'avoir tout d'un coup) Ca vous semble bien ?
Par contre, si je fais ca je dois me garder tous les guid des users pour lier les tables... Ce qui est assez lourd. (Je suis pas fan fan)
Par contre, en faisant comme ca on perd une partie qui me semblait intéressante. En effet, la base ASPNETDB peut etre une base commune pour un ensemble d'application. Et seulement ensuite, on creer plusieurs base par métier par exemple. Ca permet d'avoir un login/mdp commun à toutes les applis.
Enfin, bon je me pose peut etre trop de question. Je trouve dommage qu'il n'y ai pas plus de tuto sur les 'best practice' de début de projet... (Enfin, je cherche peut etre pas bien :p)
@ bientot
Merci pour la reponse, qui me va qu'à moitié :p désolé.
Deja pour pas m'embêter, je préfère créer la base ASPNETDB puis la renommer en ce que je veux, puis ajouter mes tables. (Cela permet d'avoir tout d'un coup) Ca vous semble bien ?
Par contre, si je fais ca je dois me garder tous les guid des users pour lier les tables... Ce qui est assez lourd. (Je suis pas fan fan)
Par contre, en faisant comme ca on perd une partie qui me semblait intéressante. En effet, la base ASPNETDB peut etre une base commune pour un ensemble d'application. Et seulement ensuite, on creer plusieurs base par métier par exemple. Ca permet d'avoir un login/mdp commun à toutes les applis.
Enfin, bon je me pose peut etre trop de question. Je trouve dommage qu'il n'y ai pas plus de tuto sur les 'best practice' de début de projet... (Enfin, je cherche peut etre pas bien :p)
@ bientot
nhervagault
Messages postés
6063
Date d'inscription
dimanche 13 avril 2003
Statut
Membre
Dernière intervention
15 juillet 2011
37
18 mars 2010 à 21:54
18 mars 2010 à 21:54
Ah ok, si tu veux une base par métier, il est intéressant de faire une base commune
et une base par application.
Mais il est possible de faire un membership provider en se basant sur l'active directory?
Mais c'est une autre histoire.
Ensuite il est possible de faire la relation sur le nom de connexion à la place du guid,
mais faire la relation sur le GUID est mieux.
De plus il est conseillé de faire le minimum de lien entre les 2 bases,
pour des raisons de maintenance.
La sécurité doit encadrer le métier et éviter d'interférer dessus.
Cela permettrait de changer de technique de sécurité, active directory, base de données,
serveur d'identité ou infocard, ....
Bon dev
et une base par application.
Mais il est possible de faire un membership provider en se basant sur l'active directory?
Mais c'est une autre histoire.
Ensuite il est possible de faire la relation sur le nom de connexion à la place du guid,
mais faire la relation sur le GUID est mieux.
De plus il est conseillé de faire le minimum de lien entre les 2 bases,
pour des raisons de maintenance.
La sécurité doit encadrer le métier et éviter d'interférer dessus.
Cela permettrait de changer de technique de sécurité, active directory, base de données,
serveur d'identité ou infocard, ....
Bon dev
