MVC, Entity Framework, бизнес-логика

Хотя я считаю, что хорошо разбираюсь в MVC (из Rails), я изучаю «MS Way» с ASP.NET MVC.

Кроме того, я также изучаю Entity Framework.

Я создал объект под названием User в моей папке Models. Используя LINQ to EF, я могу извлекать записи, и все в порядке.

Теперь я хочу добавить бизнес-логику (или, как я называю, предметную) логику. Но, на мой взгляд, EF - это скорее DAL. Итак, я создал папку под названием «Домен» и там я создал класс для некоторых бизнес-правил.

Один из них - зашифровать пароли.

Поэтому я могу использовать в своих контроллерах следующее:

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

Кроме того, это означает, что логика домена может получить доступ к пользователю EF, когда ему необходимо сохранить в БД.

Это логично?

Любые рекомендации приветствуются.

Спасибо!


entity-framework asp.net-mvc business-logic
person cbmeeks    schedule 21.09.2010    source источник
comment
В чем именно заключается ваш вопрос?   -  person Sander Rijken    schedule 21.09.2010
comment
Кстати, я сказал зашифровать пароль. Я имел ввиду HASH. Забавно, я фактически переписываю старую систему, созданную для нас, где пароли зашифрованы. Я использую SHA256 с хорошим значением соли.   -  person cbmeeks    schedule 23.09.2010

Ответы (3)


arrow_upward
3
arrow_downward

Единственное, что я хотел бы спросить, это: «Почему пользователь, человек, может знать, как зашифровать или хешировать пароль?»

Шифрование пароля будет частью уровня приложения. Это почти анти-DDD.

person John Farrell    schedule 21.09.2010
comment
Я бы не стал шифровать пароли. Я допустил опечатку, когда спрашивал. - person cbmeeks; 23.09.2010
comment
@cbmeeks - ответ остается прежним. Это проблема прикладного уровня. - person John Farrell; 23.09.2010

arrow_upward
2
arrow_downward

Это немного зависит от проекта, но обычно мы:

  • не помещайте код в модели EF, все модели хранятся в отдельном проекте
  • поместите бизнес-уровень между кодом MVC и EF. В предыдущих версиях EF это использовалось для сопоставления объектов EF с объектами домена, но с POCO это больше не требуется. Любое кеширование будет выполняться на этом уровне.
  • использовать вспомогательный или служебный класс для шифрования
person Shiraz Bhaiji    schedule 21.09.2010

arrow_upward
1
arrow_downward

Я думаю, что вы ищете POCO (простые старые объекты CLR). В одной руке у вас есть объекты EF. С другой стороны, у вас есть домен или бизнес-объекты ... а затем вы можете сопоставить их ... ваш уровень DAL должен возвращать сущности POCO, а не сущности EF ... по крайней мере, так сделано в трехуровневом приложении. Я полагаю, что это тот же подход в приложении MVC ...

Я прав?

person pabloide86    schedule 21.09.2010