Exemple d'application métier avec Silverlight 3 et .NET RIA Services - Partie 9 : POCO et Fournisseur d'authentification

Cet article est la traduction la plus fidèle possible de l'article original de Brad Abrams, Business Apps Example for Silverlight 3 RTM and .NET RIA Services July Update: Part 9: POCO and Authentication Provider.

J'ai eu plein de bons commentaires sur ma série mettant à jour ma présentation du Mix09 intitulée « building business applications with Silverlight 3 ». Certains clients ont posé des questions sur la version « live » que je fais tourner sur un des serveurs de Scott Hanselman (Merci Scott !).

La démo requiert les éléments suivants (tout est 100 % gratuit) :

• Visual Studio 2008 Express SP1 (qui comprend SQL Server 2008 Express) ;
• Silverlight 3 ;
• .NET RIA Services.

Vous pouvez, de plus, télécharger les fichiers de la démo complète et jeter un œil à l'application en cours d'exécution.

Scott m'a donné un accès FTP et un serveur web, mais je ne voulais pas l'embêter avec la création d'une base de données (bien qu'il me l'ait proposé). Alors j'ai pensé utiliser le support POCO de RIA Services afin de juste obtenir des données de ces bons vieux objets CLR. Personnellement, je pense que beaucoup trop de nos échantillons montrent uniquement l'Entity Framework… donc, c'est une bonne excuse pour mettre cela en valeur.

Donc, revenons à votre diagramme d'application, je veux utiliser ce poste pour me concentrer sur POCO comme une source de données.

D'abord, mon but était de faire le minimum de modifications. Je ne voulais surtout ni toucher au client, ni modifier aucune de mes logiques métier non plus. Je voulais juste passer l'application d'EF \ SQL à une source de données POCO.

Il s'avère que ce fut assez simple à faire. J'ai d'abord supprimé le fichier northwind.mdfd'App_Data, puis j'ai supprimé le modèle EF.

Ensuite, j'ai ajouté une classe SuperEmployee… Je suis allé de l'avant et j'ai ajouté les métadonnées directement.

public class SuperEmployee
{
 
   [Key]
   [ReadOnly(true)]
   public int EmployeeID { get; set; }
 
   public DateTime LastEdit {get;set;}
 
   [Display(Name = "Name")]
   [Required(
       ErrorMessage = "Super hero's require names!!")]
   public string Name { get; set; }
 
   [Display(Name = "Gender")]
   [RegularExpression("^(?:m|M|male|Male|f|F|female|Female)$",
       ErrorMessage = "Even super heros are  M\\F or Male\\Female!")]
   public string Gender { get; set; }

Puis j'ai créé la classe SuperEmployeeList qui contient toutes les données

List<SuperEmployee> list = new List<SuperEmployee>()
{       
        
       new SuperEmployee() {
       EmployeeID=1,
       Gender="Male",
       Issues=982,
       Name = "Alfred",
       Origin="Human",
       Publishers="DC",
       Sites="first appears in Batman #16"},
               

       new SuperEmployee() {
       EmployeeID=2,
       Gender="Male",
       Issues=518,
       Name = "Alfred E. Neuman",
       Origin="Human",
       Publishers="Ec",
       Sites="first appears in MAD #21"},

Ensuite, j'ai ajouté quelques méthodes simples pour faire encapsuler l'accès

public IEnumerable<SuperEmployee> GetEmployees()
{
   return list.ToArray();
}
 
public void Add(SuperEmployee emp)
{
   list.Add(emp);
}

Puis quelques petites modifications à mon implémentation de DomainService. Remarquez ici que je dérive directement de DomainService plutôt que d'utiliser les classes LinqToSqlDomainService ou EntityFrameworkDomainService. Je pense que ce sera raisonnablement commun.

[EnableClientAccess()]
public class SuperEmployeeDomainService : DomainService
{
   SuperEmployeeList Context = new SuperEmployeeList();
   public IQueryable<SuperEmployee> GetSuperEmployees()
   {
       return Context.GetEmployees().AsQueryable();
   }
 
   public IQueryable<SuperEmployee> GetSuperEmployee(int employeeID)
   {
       return Context.GetEmployees().ToList()
           .Where(emp => emp.EmployeeID == employeeID).AsQueryable();
           
   }
 
   public void InsertSuperEmployee(SuperEmployee superEmployee)
   {
       Context.Add(superEmployee);
   }
public override void Submit(ChangeSet changeSet)
{
   base.Submit(changeSet); 
   //todo: Submit changes to the store.. (for example, save to a file, etc
}

Je devrais aussi surcharger Submit afin de mettre de côté les modifications (disons dans un fichier ou une sorte de magasin de sauvegarde). Mais pour la démo je voulais les garder statiques afin que personne ne puisse entrer de mauvaises données sur mon site.

Appuyez sur F5 et tout le reste fonctionne… Aucun changement pour le client Silverlight ou le client ASP.NET (pour SEO)… Cette même flexibilité vous permet de passer d'une technologie d'accès aux données à une autre sans avoir à mettre à jour tous vos clients.

Authentification▲

Comme vous l'avez vu dans un précédent billet, nous avons un nouveau modèle très cool qui vous propose un support pour la connexion et la création d'un nouvel utilisateur.

J'ai *dû* activer cela dans la démo, au moins pour que les gens puissent jouer avec. Par défaut, on utilise aspnetdb.mdb et SQLExpress… donc ceci avait besoin d'être mis à jour tout comme l'exemple ci-dessus.

Parce que nous nous branchons simplement dans le système d'adhésion ASP.NET livré dans ASP.NET 3.0, c'est un domaine assez bien exploré et documenté. Mais voici la brève à ce sujet.

Dans le web.config du projet de serveur, sous la section system.web ajoutez ceci :

 

Sélectionnez

    <membership defaultProvider="SimpleMembershipProvider">
     <providers>
       <add name="SimpleMembershipProvider"
            type="MyApp.Web.SimpleMembershipProvider"
            minRequiredPasswordLength="2"
            minRequiredNonalphanumericCharacters="0" />
     </providers>
   </membership>

Ensuite, il suffit d'implémenter SimpleMembershipProvider… Ici, j'ai fait un modèle de démonstration uniquement qui accepte n'importe quels identifiants utilisateur et mots de passe. 

 

Sélectionnez

public class SimpleMembershipProvider : MembershipProvider
  {
     public override bool ValidateUser(string username, string password)
     {
       return true;
     }
     public class MyUser : MembershipUser
     {
 
     }
     public override MembershipUser CreateUser(string username, string password, string email, string passwordQuestion, string passwordAnswer, bool isApproved, object providerUserKey, out MembershipCreateStatus status)
     {
       status = MembershipCreateStatus.Success;
       return new MyUser();
  }

Il est clair que dans une application réelle, vous allez vouloir vous brancher sur votre système de gestion des utilisateurs. Mais, une fois encore, parce que le système d'ASP.NET a été en place depuis si longtemps il y a du support pour à peu près n'importe quel système. Regardez aussi ce super livre sur le sujet : Professional ASP.NET 2.0 Security, Membership, and Role Management de Stefan Schackow.

Ceci conclut donc la neuvième partie de cette série d'articles sur le développement d'applications métier avec Silverlight 3 et .NET RIA Services. La dixième partie abordera LINQ to SQL.

Je tiens ici à remercier Brad Abrams de nous avoir autorisés à traduire son article.
Je remercie également ClaudeLELOUP pour sa relecture et ses propositions.