ASP.NET Membership object in Business Layer

Hi experts,
I'm building an 3-layered ASP.NET application and make use of the built in Membership concept.
Therefore my database has the automatically created tables aspnet_Users and aspnet_Membership.
In my application one company can have multiple logins. And in my user management I want to see which login belongs to what company. That's why  I have a relation in my database between the aspnet_Users table and another table called "company".
So far so good.
Now in my Business Layer I have a class called "Company". This class should have a property that sets/gets a list of all logins belonging to that company. My property now looks like this (see code).
This works if I reference System.Web.Security in my Business Layer.
But that's where I start thinking - this can't be right.
I want to design my Business Layer independent from my Presentation Layer and now I have a Membership object in the BL that is especially designed for ASP.NET.

What would be the correct way to do it?

Thanks for your help!
/// <summary>
        /// Gets or sets the accounts.
        /// </summary>
        /// <value>The accounts.</value>
        public Membership Accounts { get; set; }

Open in new window

arthrexAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

rdogmartinCommented:
I ran into the same problem as I didn't want to have a reference to System.Web.dll in my business layer. There is really no good solution, but two ideas are:

1. Keep your membership logic in the web layer.
2. Create a custom membership class in your business layer and populate it with data extracted from the ASP.NET MembershipUser objects in your web layer.

The second idea is clumsy and only viable if you have extensive business logic you need to keep in the business layer. In my app I just kept all the membership stuff in the web layer.

I wish MS didn't put the membership stuff in System.Web.dll...

Roger
0
guru_samiCommented:
Bare with me as my answer might not make sense but what you might be looking into is Dependency Injection.
Check if Microsoft ObjectBuilder is helpful.
Sorry for vague answer...I know its doable but can't come up with an explanation.
0
arthrexAuthor Commented:
Hey everybody,
thanks for your answers. But I guess the correct answer is that Membership can be used in other scenarios than web. So I just reference it now in the BusinessLayer. As Roger said, it looks weird that they put it into the System.Web dll. But I guess we have to live with that
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Programming Theory

From novice to tech pro — start learning today.