Conception de l'interface utilisateur (et plusieurs couches) en asp.net

Une grande partie du succès d'une application Web dépend de la qualité de son interface utilisateur. En ce qui concerne les utilisateurs finaux, l'interface utilisateur est

les applications: les utilisateurs ne sont pas intéressés par les détails du modèle de données ou la conception des classes d'accès aux données.

Dans une application Web ASP.NET, l'interface utilisateur se compose d'une série de pages .aspx qui sont rendu au navigateur en utilisant HTML standard. Conception de l'interface utilisateur est simplement une question de décider quelles pages sont nécessaires (et dans quel ordre) - et de remplir ces pages avec les contrôles appropriés.

HTML standard dispose d'un ensemble étonnamment limité de commandes utilisateur:

• Boutons

• Les zones de texte

• Les listes déroulantes

• Cochez les cases

• Les boutons radio

Toutefois, ASP.NET offre de nombreux contrôles qui misent sur ces commandes de base. Par exemple, vous pouvez utiliser un contrôle GridView pour présenter les données d'une base dans un format tabulaire.

Tous les contrôles ASP.NET sont finalement rendus au navigateur, en utilisant la norme HTML. En conséquence, même les contrôles ASP.NET de plus compliquées sont tout simplement des composites constitués de contrôles HTML standard et des éléments de mise en forme HTML (comme les tables).

Conception de l'interface utilisateur peut rapidement devenir l'aspect le plus complexe d'une application Web. Bien que la conception de l'interface utilisateur n'a pas de règles dures et rapides, voici quelques lignes directrices que vous devriez garder à l'esprit:

• Considérez la façon dont souvent l'utilisateur utilisera chaque page et le degré de familiarité qu'il ou elle sera à l'application. Si l'utilisateur travaille avec la même page, encore et encore tout au long de la journée, essayez de faire l'entrée de données le plus efficace possible. Cependant, si l'utilisateur doit utiliser la page qu'une seule fois dans un certain temps, se tromper sur le côté de faire la page d'auto-explicative afin que l'utilisateur n'a pas à lutter pour comprendre comment utiliser la page.

• Rappelez-vous que l'utilisateur est en contrôle de l'application et les utilisateurs sont assez imprévisibles. Les utilisateurs pourraient abandonner au milieu d'une séquence d'entrée de données, ou frapper le bouton Précédent du navigateur de façon inattendue.

• Certains utilisateurs apprécient la souris, d'autres comme le clavier. Ne forcez pas votre préférence sur l'utilisateur: assurez-vous que votre interface fonctionne bien pour la souris ainsi que les utilisateurs du clavier.

• Revue des prototypes de la conception de l'interface utilisateur avec utilisateurs réels. Écoutez leurs suggestions au sérieux. Ils ont probablement une meilleure idée que vous faites de ce que l'interface utilisateur devrait ressembler et comment il doit se comporter.

• Les sites Web de l'étude que vous envisager d'avoir de bonnes interfaces.

Concevoir la couche Business Rules

Les règles métier sont la partie d'un programme qui met en œuvre les politiques commerciales dictées par l'application. Voici quelques exemples de règles métier:

• Si un client est accordé une demande de crédit?

• Combien d'une réduction doit être appliquée à un ordre donné?

• Combien de copies du formulaire 10432 / J doivent être imprimés?

• Combien d'expédition et de manutention devraient être cloué sur une facture?

• Quand un élément d'inventaire qui exécute en stock devrait être réorganisé?

• Combien de congés de maladie doit obtenir un employé avant de gestionnaires se demandent si il ou elle a fait du ski plutôt que de rester à la maison malade?

• Quand un compte à payer devrait être accordée à profiter de rabais tout en maximisant flotteur?

La clé de la conception de la partie business-règles d'une application est tout simplement d'identifier les règles métier qui doivent être mises en œuvre et de les séparer autant que possible d'autres parties du programme. De cette façon, si les règles changent, seul le code qui implémente les règles doit être changé.

Par exemple, vous pouvez créer une classe pour gérer les politiques de remise. Ensuite, vous pouvez appeler les méthodes de cette classe lorsque vous avez besoin pour calculer la réduction d'un client. Si les changements de politique de rabais, la classe d'actualisation peut être mis à jour pour refléter la nouvelle politique.

Idéalement, chaque règle d'affaires devrait être mise en œuvre qu'une seule fois, dans une seule classe qui est utilisé par chaque programme qui en a besoin. Trop souvent, les politiques commerciales sont mises en œuvre maintes et maintes fois dans de multiples programmes - et si les changements de politique, des dizaines de programmes doivent être mis à jour. (Cela fait mal, même à penser, non?)

Conception de la couche d'accès aux données

Une grande partie du travail de conception de la couche d'accès aux données consiste à concevoir la base de données elle-même. Voici quelques conseils sur la conception de la couche d'accès aux données:

• Pour commencer, vous devez décider quel serveur base de données à utiliser (par exemple, SQL Server ou Oracle).

• Vous aurez besoin de concevoir les tableaux qui composent la base de données et de déterminer les colonnes de chaque table exigera.

• Vous devez également décider quelles sont les techniques de base que vous allez utiliser pour accéder aux données. Par exemple, allez-vous écrire des classes d'accès aux données personnalisées qui accèdent à la base de données directement, ou allez-vous utiliser le contrôle SqlDataSource de ASP.NET pour accéder à la base de données? Et allez-vous utiliser des procédures stockées ou de code les instructions SQL utilisées pour accéder aux données directement dans le code de l'application?