Пользовательский MembershipProvider с веб-интерфейсом и DAL - PullRequest
Новая
       29

Пользовательский MembershipProvider с веб-интерфейсом и DAL

1 голос
/ 07 января 2010

Я работаю над решением ASP.NET с 2 проектами. Одним из них является веб-интерфейс, а другой содержит мою бизнес-логику. Я использую LINQ to SQL для доступа к данным во втором проекте.

Помимо моей базы данных, у меня есть таблица с именем Users, в которой хранится информация о пользователях.

Я начал реализовывать MembershipProvider. Я заметил, что MembershipUser связан с MembershipProvider. Какой самый правильный способ заставить моего BLL / DAL говорить о пользователях? Если я минимально реализую MembershipUser и всякий раз, когда пользователь вызывает метод, он вызывает, например,. GetUserInfo () в моем BLL / DAL, чтобы получить полную информацию о пользователе?

Или я должен заставить методы класса MembershipUser вызывать мои пользовательские методы класса «Users» (например, обертку) в BLL / DAL (этот пользовательский класс пользователей не связан с linq)?

Или я могу как-то расширить Linq до класса sql "CFUsers" для расширения MembershipUser.

Надеюсь, это имеет смысл.

1 Ответ

1 голос
/ 07 января 2010

Обычно я вижу это как отдельные сущности, так как MembershipUser вращается вокруг членства, что является общей проблемой, а пользователь в вашей системе вращается вокруг того, что влечет за собой ваш домен. Я вижу вашу точку зрения, где обе эти сущности могут содержаться в одной,так.Профили - это, безусловно, самый простой способ.

Хотя на документах MSDN есть http://msdn2.microsoft.com/en-us/lib...US,VS.80).aspx и хорошее прохождение от Скотта Гатри на http://weblogs.asp.net/scottgu/archi...18/427754.aspx

Как всегда Это зависитна какие ваши цели.Добавление в профиль - это простой механизм для получения дополнительных данных.Он требует очень мало настроек и делает информацию легко доступной для веб-приложения.Это может быть не там, где вы хотите хранить данные этого типа;если нет, то это не решение проблемы.

Если это не подходит, создание нового поставщика, полученного из значения по умолчанию (для наследования того, что у вас уже есть), является отличным вариантом.и, конечно, окончательный http://codesmart.wordpress.com/2009/03/27/extending-the-microsoft-aspnet-membership-provider/

...