views:

192

answers:

1

Hi,

I'm working on an ASP.NET solution with 2 projects. One is the web interface and the other contains my business logic. I'm using LINQ to SQL for my data access in the second project.

Apart of my database, I have a table called Users which holds user information.

I've started to implement a MembershipProvider. I notice that MembershipUser is coupled with MembershipProvider. What is the most correct way of getting my BLL/DAL to talk about Users? Should I minimally implement MembershipUser and whenever a user calls a method, it will call for eg. GetUserInfo() in my BLL/DAL, to get complete information about the user?

Or should I make the MembershipUser class methods call my custom "Users" class methods (like a wrapper) in the BLL/DAL (this custom users class is not related to linq)?

Or can I somehow extend the Linq to sql class "CFUsers" to extend MembershipUser.

I hope this makes sense.

+1  A: 

I usually see this a seperate entities as MembershipUser revolves around membership which is a generic concern and a user in your system revolves around whatever your domain entails, I do see your point of view where both these entities could be contained in one, so. Profiles is definitely the easiest way to go.

There's a walkthough on the MSDN docs at http://msdn2.microsoft.com/en-us/lib...US,VS.80).aspx and a good walkthrough from Scott Guthrie at http://weblogs.asp.net/scottgu/archi...18/427754.aspx

As always It depends on what your goals are. Adding to Profile is a simple mechanism for additional data. It requires very little in the way of customization and makes the info easily available for the web application. This may not be where you want to store this type of data; if not, it is a non-solution.

If this does not fit, making a new provider derived from the default (to inherit what you already have) is a great option. and of course the ultimate http://codesmart.wordpress.com/2009/03/27/extending-the-microsoft-aspnet-membership-provider/

almog.ori