E
ePrint
Asp.Net v2.0
I have created a web application and I am using it from a single website and
database. The web application has different ‘portals’ – each independent and
I am using the Membership & Roles ApplicationName to separate out my
different groups of users within the membership database.
I had been having problems with ‘random’ bugs - as though my Membership
database was 'sharing' information between users and applications rather than
keeping it separate.
I have now come across this article. Is what it is saying about Membership
being a singleton true?
---------------------------------------------------------------------------------
The Membership and Role classes use the singleton design pattern. I did not
instantiate either one in my code to access their ApplicationName properties,
I just used the instance that is automatically created for me. All
applications running on the same web server share the same instances of these
classes, and when one application changes a property, all applications are
affected. How can different applications use separate roles and users without
stepping on each other then?
If your applications are big enough to each have their own web server - or
web farm - there is no problem. You can set the application names in
machine.config and not worry about it. They can share a centralized
membership services database without interfering with each other. You could
set up separate databases to support membership services for each
application, at the loss of some centralization. You could also just use the
stored procedures directly, rather than accessing them through the Membership
and Role methods. This approach lets you set the application name directly,
without reference to the properties.
http://microsoft.apress.com/feature/59/membership-information-and-multiple-applications
I have created a web application and I am using it from a single website and
database. The web application has different ‘portals’ – each independent and
I am using the Membership & Roles ApplicationName to separate out my
different groups of users within the membership database.
I had been having problems with ‘random’ bugs - as though my Membership
database was 'sharing' information between users and applications rather than
keeping it separate.
I have now come across this article. Is what it is saying about Membership
being a singleton true?
---------------------------------------------------------------------------------
The Membership and Role classes use the singleton design pattern. I did not
instantiate either one in my code to access their ApplicationName properties,
I just used the instance that is automatically created for me. All
applications running on the same web server share the same instances of these
classes, and when one application changes a property, all applications are
affected. How can different applications use separate roles and users without
stepping on each other then?
If your applications are big enough to each have their own web server - or
web farm - there is no problem. You can set the application names in
machine.config and not worry about it. They can share a centralized
membership services database without interfering with each other. You could
set up separate databases to support membership services for each
application, at the loss of some centralization. You could also just use the
stored procedures directly, rather than accessing them through the Membership
and Role methods. This approach lets you set the application name directly,
without reference to the properties.
http://microsoft.apress.com/feature/59/membership-information-and-multiple-applications