MVC, Entity Framework, Бизнес-логика - PullRequest
       16

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

1 голос
/ 21 сентября 2010

Хотя я считаю, что хорошо разбираюсь в 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 User, когда ему необходимо сохранить ее в БД.

Эта логика звучит?

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

Спасибо!

Ответы [ 3 ]

3 голосов
/ 21 сентября 2010

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

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

2 голосов
/ 21 сентября 2010

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

  • не вводите код в модели EF, все модели хранятся в отдельном проекте
  • Поместите бизнес-уровень между кодом MVC и EF. В предыдущих версиях EF это использовалось для отображения объектов EF на объекты домена, но с POCO это больше не требуется. В этом слое будет выполняться любое кэширование.
  • использовать вспомогательный или служебный класс для шифрования
1 голос
/ 21 сентября 2010

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

Я прав?

...