MVC, Entity Framework, Business Logic

Bien que je crois avoir une bonne compréhension de MVC (de Rails), j'apprends le "MS Way" avec ASP.NET MVC.MVC, Entity Framework, Business Logic

J'apprends aussi Entity Framework.

J'ai créé une entité appelée Utilisateur dans mon dossier Modèles. En utilisant LINQ to EF je peux récupérer des enregistrements et tout est bon.

Maintenant, je veux mettre une logique métier (ou ce que j'appelle, domaine). Mais dans mon esprit, EF est plus de la DAL. J'ai donc créé un dossier appelé "Domain" et là, j'ai créé une classe pour certaines règles métier.

L'un d'entre eux consiste à crypter les mots de passe.

Je peux donc utiliser ce qui suit dans mes contrôleurs:

string password = Domain.User.EncryptPassword(string salt, string password);

En outre, cela signifie que la logique de domaine peut accéder à l'utilisateur EF quand il a besoin de persister à la DB.

Est-ce logique?

Toutes les recommandations ont été appréciées.

Merci!

Source

2010-09-21 cbmeeks

Quelle est exactement votre question? –

BTW, j'ai dit "crypter le mot de passe". Je voulais dire HASH. C'est drôle, je suis en train de réécrire un ancien système qui a été fait pour nous où les mots de passe sont cryptés. J'utilise SHA256 avec une bonne valeur de sel. – cbmeeks

La seule chose que je voudrais demander est: "Pourquoi un utilisateur, une personne, sait-il crypter ou hacher un mot de passe?"

Le cryptage d'un mot de passe ferait partie d'une couche Application. C'est presque anti-DDD.

Source

2010-09-21 19:20:33 jfar

Je ne crypterais pas les mots de passe. J'ai fait une faute de frappe en demandant. – cbmeeks

@cbmeeks - La réponse reste la même. C'est un problème de couche application. – jfar

Je pense que ce que vous cherchez est POCO (Plain Old CLR Objects). D'une part vous avez vos entités EF. D'un autre côté, vous avez votre domaine ou vos entités commerciales ... et vous pouvez ensuite les mapper ... votre couche DAL doit renvoyer des entités POCO et non des entités EF .. du moins c'est comme cela dans une application à trois niveaux. Je suppose que c'est la même approche dans une application MVC ...

Ai-je raison?

Source

2010-09-21 19:21:09 pabloide86

Cela dépend un peu sur le projet, mais en général nous:

ne mettent pas de code dans les modèles EF, tous les modèles sont stockés dans un séparé projet
place une couche d'affaires entre le MVC code et EF. Dans les versions précédentes de EF, cela servait à mapper les objets EF aux objets de domaine, mais avec POCO, cela n'est plus nécessaire. Toute mise en cache serait effectuée dans cette couche.
utiliser une aide ou une classe utilitaire pour le cryptage

Source

2010-09-21 19:28:20

Répondre

Questions connexes