Application de la logique métier pour former des éléments dans ASP.NET MVC

Question

Je suis à la recherche de bonnes pratiques pour appliquer une logique métier afin de former des éléments dans une application ASP.NET MVC. Je suppose que les concepts s'appliqueraient à la plupart des modèles MVC. L'objectif est de faire en sorte que toute la logique métier provienne du même endroit.

J'ai une forme de base avec quatre éléments:
Textbox: pour les données entrant dans
Checkbox: pour l'approbation du personnel
Checkbox: pour l'approbation du client
Bouton: pour la présentation sous forme

La zone de texte et deux cases à cocher sont des champs d'une base de données accédée à l'aide de LINQ to SQL. Ce que je veux faire est de mettre la logique autour des cases à cocher sur qui peut les vérifier et quand.

vraie table (peu idiot, mais c'est un exemple):

when checked || may check Staff || may check Client 
Staff | Client || Staff | Client || Staff | Client 
    0  0 || 1  0   0  1 
    0  1 || 0  0   0  1 
    1  0 || 1  0   0  1 
    1  1 || 0  0   0  1 

Il y a deux rôles de sécurité, le personnel et le client; Le rôle d'une personne détermine qui elle est, les rôles sont conservés dans la base de données avec l'état actuel des cases à cocher.

je peux simplement stocker les utilisateurs rouler dans la classe d'affichage et activer et désactiver les cases à cocher en fonction de leur rôle, mais cela ne semble pas bon. C'est mettre de la logique dans l'interface utilisateur pour contrôler quelles actions peuvent être prises.

Comment puis-je obtenir la majeure partie de ce contrôle dans le modèle? Je veux dire que j'ai besoin de contrôler les cases à cocher activées, puis vérifier les résultats dans le modèle lorsque le formulaire est posté, il semble donc le meilleur endroit pour cela à l'origine.

Je cherche une bonne approche pour construire ce, quelque chose à suivre comme je construis l'application. Si vous connaissez de bonnes références qui expliquent ces bonnes pratiques, c'est aussi très apprécié.

Answer 1

Mon approche a tendance à être d'écrire la vue afin que l'utilisateur peut faire quoi que ce soit et de mettre toute ma validation dans la couche modèle/service. Ensuite, quand tout fonctionnera, j'ajouterai la logique de jQuery pour que l'utilisateur soit plus conscient de ce qu'il peut faire et ne puisse pas faire et pour éviter les postbacks inutiles partout où cela est nécessaire.

Je pense qu'il est une erreur de compter sur le navigateur pour bloquer quelque chose que le serveur permettra. La publication est trop facile à truquer et javascript peut facilement être désactivé. Cependant, lorsque javascript peut être utilisé pour améliorer l'expérience de l'utilisateur ou pour économiser des efforts de la part de votre serveur, vous devriez le faire. Et oui, cela signifie parfois une logique commerciale répétée, mais c'est un sacrifice qui vaut la peine d'être fait. C'est rarement du code répété réel. Du coté du serveur c'est "si X est coché et Y est coché, retourne un message et ne stocke pas", du côté client c'est "si X est coché, ne permets pas que Y soit vérifié".

Avez-vous du sens?

Answer 2

Si vous vouliez garder tout le bâtiment de l'interface utilisateur dans le modèle que vous aurait alors probablement besoin d'inclure un état à chaque case. Votre modèle contiendra donc un objet case à cocher qui à son tour a l'attribut state.

alors à votre avis, vous pouvez définir le drapeau activé à l'aide Model.CheckBoxName.state je suppose.

ce serait alors vrai pour tous les contrôles qui nécessitent des informations d'état qui compliqueraient trop votre modèle je pense. Personnellement, je garderais un peu de l'intelligence dans la vue que toutes les vues qui utilisent ce modèle nécessiteront le drapeau d'état.

IMO un modèle devrait être aussi simple que possible. Vous pourriez avoir un FormViewModel qui décrit l'état de divers contrôles qui supprimeraient l'état du modèle et je pense que c'est une bonne idée. @pdr fait un bon point et plutôt que d'avoir une case à cocher qui est désactivée, vous pouvez envisager d'avoir une étiquette. mais vous avez toujours le problème de simuler une publication.

qui peut être facilement capturé car votre model viewview peut vous indiquer s'il faut ignorer les soumissions des contrôles désactivés. Quoi qu'il en soit, si vous voulez cela dans le modèle, alors je ferais un model de forme et aurais l'état là-dedans. Je vérifie également, sur poste, si vous pouvez accepter des valeurs de contrôles disbaled.