Aspnetdb & co

Bonjour,

J'ai une question d'architecture !
C'est relativement simple... Quand je cré un projet, j'ai la creation d'une base de données aspnetdb.mdf. J'en suis tres content car cela me gére toute la partie login, roles, profils...

Ensuite, j'ai 2 choix :
1) Ajouter des tables dans la base aspnetdb pour réaliser mon application.
2) Creer une nouvelle base de données pour réaliser mon appication.

Deja, vous partiriez sur quel choix ?
Ensuite, si je prend le 2eme choix j'ai regardé un petit tuto (http://msdn.microsoft.com/en-us/library/aa479394.aspx) je vais pouvoir faire un 'lien' etre mes 2 bases... mais qui n'est pas tres logique.
Imaginons:
J'ai ma base de données auto [ASPNETDB] avec une table [aspnet_User] et un champs [UserName]
Ensuite, j'ai une basse de données [LIBRARY] une table [book] et un champs [UserName] J'ai donc un 'lien' entre les 2 bases. mais si dans ASPNETDB je cange ce nom, alors ma table book de Library ne sera plus en accord avec l'autre base de données... et si je travail non pas avec les UserName mais avec les guid(uniqueidentifier) et bien je vais devoir requeter sur les 2 base à chaque select...

Bref, je suis un peu perdu !
Si vous avez des idées ? Ou des 'best parctice' sur le sujet, je suis preneur...

merci !

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

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

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