Вы не можете делать такие вещи с поставщиком членства ASP.NET, то есть записывать пользовательские обновления в таблицы.
Если бы это было так просто, у меньшего количества людей были бы проблемы / проблемы с этим. =)
Даже не беспокойтесь о добавлении таблиц членства в ASP.NET в EDMX - вы не будете знать, как эти таблицы действительно работают вместе. Забудьте о попытке представить его как «модель».
Мой совет: не пытайтесь привязывать членство MembershipProvider в качестве модели (т.е. не создавайте строго типизированное представление), просто вызывайте методы Membership непосредственно из вашего контроллера.
Здесь мы начинаем скучать по «перетаскиванию» веб-форм, не можем попасть на элемент управления ChangePassword. =)
Лучше всего было бы создать обычный вид (не строго типизированный), а затем иметь обычные кнопки, которые публикуют методы контроллера.
Не пытайтесь пройти через объект как модель, получите поля в коллекции Request.Form.
[HttpPost]
public ActionResult ChangePassword()
{
string userName = Request.Form["userName"];
string passWord = Request.Form["passWord"];
MembershipProvider.ChangePassword(userName, password);
return View("ChangePasswordSuccess");
}
Приведенный выше код будет (примерно) эквивалентен прохождению через строго типизированный объект User, изменению пароля и вызову UpdateModel.
Конечно, вы могли бы реализовать своего собственного провайдера членства, но я не верю, что реализация нестандартного провайдера просто для того, чтобы сделать ваш код "проще", должна быть драйвером, потому что если не закодировано должным образом (что непросто) ) вы ставите под угрозу множество встроенных функций безопасности и множество возможностей управления учетными записями поставщика членства ASP.NET, которые мы считаем само собой разумеющимися.