MVC, Entity Framework, Business Logic

1
votes

Although I believe I have a good grasp on MVC (from Rails), I'm learning the "MS Way" with ASP.NET MVC.

Also, I am learning Entity Framework as well.

I've created an Entity called User in my Models folder. Using LINQ to EF I can retrieve records and all is good.

Now, I want to put some business (or what I call, domain) logic in. But in my mind, EF is more of the DAL. So I created a folder called "Domain" and in there, I created a class for some business rules.

One of them is to encrypt passwords.

So I can use the following in my controllers:

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

Also, that means the domain logic can access the EF User when it needs to persist to the DB.

Is this logic sound?

Any recommendations appreciated.

Thanks!

3
asp.net-mvcentity-frameworkbusiness-logic
What exactly is your question? – Sander Rijken
BTW, I said "encrypt password". I meant HASH. Funny, I am actually re-writing an old system that was done for us where passwords are encrypted. I use SHA256 with a good salt value. – cbmeeks

3 Answers

3
votes

The only thing I would ask is: "Why would a user, a person, know how to encrypt or hash a password?"

Encrypting a password would be part of an Application layer. This is almost anti-DDD.

2
votes

It depends a bit on the project, but generally we:

  • do not put any code in the EF models, all models are stored in a seperate project
  • place a business layer between the MVC code and EF. In previous versions of EF this would be used to map EF objects to domain objects, but with POCO this is no longer needed. Any caching would be done in this layer.
  • use a helper or utility class for encryption
1
votes

I think what you are looking for is POCO (Plain Old CLR Objects). In one hand you have your EF entities. In the other hand you have your Domain or Business Entities... and then you can map them... your DAL Layer must return POCO entities and not EF entities.. at least that's how is made in a 3-tier application. I suppose it's the same approach in a MVC application...

Am I right?