1

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

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

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

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

Или я могу каким-то образом расширить Linq на sql-класс «CFUsers», чтобы расширить членство в UserhipUser.

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

ответ

1

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

Там в walkthough на документы 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/