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

Question

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

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

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

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

Или я могу каким-то образом расширить Linq до sql-класса "CFUsers", чтобы расширить MembershipUser.

Я надеюсь, что в этом есть смысл.

Answer 1

Обычно я рассматриваю это как отдельные сущности, поскольку 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/