I have the following database schema (in the early stages at the moment):
Everything on the right is created by the ASP.NET Provider model. They were a bunch of automatically generated tables that were created the first time that I used the login controls.
Now, I've settled for the moment in using this schema and extending it with my own tables. I'm not looking to implement any custom Providers at the moment.
My question is, can I delete the Profiles and _MigrationHistory tables?
I'm not using the Profile Provider
I'm only using the Role and Membership Providers
Will I break the Internets if I simply get rid of the Profiles and _MigrationHistory tables?
EDIT: The Profiles Provider is disabled in web.config.
The Interwebs do not break if I delete those tables. As long as no Profile Provider is used, the tables can still be used and accessed as they normally would be. They are not regenerated and no functionality is lost. The Membership/Profile/Role Provider tables can be extended or modified (as long as constraints are kept in check) or, as I was wondering, deleted.
Related
I am creating a sort of intranet system in ASP.NET that requires me to hide/show/disable/enable certain things depending on the logged on user's role. So far I have been using ASP.NET Membership (what I learned in school) however I am running into problems with having to customize things. We need usernames and passwords but we also need to add custom fields like first name, last name, clearance level (which will be used to set the user's role when they are added) and some arbitrary descriptive fields like employee title and office location.
We're using Microsoft Access (OleDB Connection in ASP) for the bulk of our database needs and we have an employee table that stores all the info we need (like names and clearance levels). I wanted to find a way to link records in those tables to the user that was set up through ASP. We need to be able to create, edit and delete users not through the web configuration tool but through the site we're creating (it will be managed by someone not familiar with ASP). Since ASP Membership uses SQL Server, it is becoming complex for me to try and find a way to connect the user tables generated by ASP and the employee tables created for the project.
I have now read online that there are two other versions of this kind of Membership system: SimpleMembership and Identity. Just by habit I'm leaning towards the most recent iteration (Identity), however I am now reading it is harder to query the user tables for appropriate role info and such.
Which would be the best for a system that has 3 specific roles and must disable/hide specific things depending on the role? And which one would be best for allowing me to create my own Add/Edit/Delete pages for users within the system?
MembershipProvider is depricated and replaced by Asp.Net Identity. Use Identity if this is a new project. Think of migration from MembershipProvider to Identity if it is a brown-field project, but it can take a week of time.
Identity is highly customisable and it is easy to add extra fields on a user and CRUD for users is very easy, especially if you know Entity Framework.
I don't like asp.net profile provider store all profile info in one or two row in the database, but I want to use membership/profile API for authentication purpose.
Customize membership/role/profile provider requires big big upfront efforts, which may cause more mess later.
So how do people deal with that normally?
You don't have to use asp.net profiles to store additional information if you don't want to. Instead you can store it in a separate table and link it to aspnet_Users table like shown here: Storing additional information
You can use the built-in
SqlMembershipProvider, which is
installed by running
aspnet_regsql.exe.
You do not have to use profiles if
you don't like them.
Customizing membership/role/profile
providers is really not that big of
a deal.
With this question I am mostly looking for answers from people that have implemented the out-of-the-box ASP.NET membership in their own database - I've set up the tables inside my database and as far as I can see they contain mostly what I need but not everything. I will have the notion of a Firm (Company) to which Users will belong so I will have to associate the aspnet_Users with my Firms table (each user will be a member of exactly one firm).
If possible, provide some guidelines how did you do it and what I might run into if I have to modify the table design at some point in the future. Preferably I will be using the default Membership provider.
I am having trouble to decide whether to go from scratch or use what ASP.NET already offers.
I would suggest that you need to use a table-based Profile Provider implementation such as this one that Scott Guthrie blogged about. It is much better than the out-of-the-box profile provider as it allows you to define your own tables for profile information. In your case you would have a table that contains a Row per user and a FirmId and anything else you like such as nick name, social security number, whatever.
It works with the default Membership provider so you won't have to make any changes to it. There are two implementations in the example, a Stored Procedure based one and a Table based one. I prefer the second but they are both very easy to use.
The default profile provider proved a bit rubbish because it stored all of a user's information in a single field. The provider that I suggested solves this in a very efficient way.
I decided not to use ASP.NET Membership provider and its default tables because of the changes that might be introduced in future versions, so I eventually ended up using this custom Entity Framework provider by OmidID although I had to tweak it quite a lot. But I can now say that we have a rather fullproof entity framework based membership provider that we can easily maintain and indenpendent of the ASP.NET membership tables in SQL Server.
I would treat the ASP.NET membership as a separate service. Just use it as is and add any additional functionality on top of it.
In this case just create a table which links the users to the companies but don't alter the ASP.NET tables. If you have any additional information you need to store about users put this in another table which is associated with the ASP.NET membership users table.
Update: I've started using this ASP.NET MVC Area to administer users and roles https://github.com/TroyGoode/MembershipStarterKit. It comes with all the necessary models, views and controllers and is fully unit tested. Didn't take more than an hour to get it integrated into my site and up and running.
I'm new to EF4 and haven't had any experience with it before. So, bear with me if this is very simple question.
I have my POCO entities (.tt file) in BOL, the .edmx file (EDM) in DAL and my webapp in Presentation layer. All the business logic goes to BLL layer.
Here are the references:
UI->BLL-DAL-BOL
BLL->DAL-BOL
DAL->BOL
BOL->None of my project.
1- Is my understanding of layers distinction correct? Am I in the right direction?
2- How can I use ASP.NET Membership provider with entities. Should I implement membership, persistence ignorant too and map all user tables in sql server to entities?
2- How can I add custom validation? I don't mean maxlength or valid email..., I mean something like access levels. For example I want certain users be able to modify a field (say productprice) in my website. Where should I use the User.IsInRole method? the BLL doesn't have any reference to user info. should I pass some parameters to BLL (like "bool CanChangePrice") to clarify access levels?
Wow Kamyar, just a few questions wrapped up in this one;-) I'm not sure if I'll cover all the possible ground, but here goes.
ProjectStructure
- generally your structure of projects is correct, and the references you have are correct. Some may argue that you want to separate your concerns a bit and break some of the references, but personally I find your structure workable.
As a practical matter I tend to keep my EDXM and POCOs in the same project. I just have an Entities folder that contains the EDXM and Model.Context.tt, a POCO folder for Model.tt and my Virtual POCO's (below), and a Repository folder for my repository & unit of work.
I also create a file called VirtualPOCOs which is a partial class bound to the POCOs generated by your T4's. My designs tend to be pretty tightly bound to database structure. The VirtualPOCO's give me a little flexibility to deviate from DB design in those one-off situations. Not to much goes in here, just those few very specific needs every project seems to have.
You may also want to consider a repository, table data gateway, or active record setup. All of these patterns will likely be combined with Unit of Work. There are tons of design patterns and your needs or preferences may push you to one or the other. The point here is to shield the upper layers from accessing the EF4 context directly. This way you can centralize connection & transaction management and ensure upper layers are only using POCOs and not accidentally holding on to linq-to-sql objects.
Membership Provider
There is a definitely a schism between the MembershipProvider and EF. You can, however, download the source code for the SQLMembershipProvider and convert it over to use EF. I actually did this conversion. The file is about 1500 lines long, but doesn't have a huge amount of ADO code.
What you didn't ask, but I think I should address, is whether you want to use Membership provider at all. If you're doing basic membership management and roles then the Membership, Roles, and Profile provider can save you a lot of time. For an in depth tour of the capabilities check out the series over at 4GuysFromRolla (https://web.archive.org/web/20211020202857/http://www.4guysfromrolla.com/articles/120705-1.aspx).
If your needs are more complex then, IMHO, the membership provider breaks down pretty quickly. For example, when a user registers for your site you immediately have to create rows in a handful of different tables. Well, the membership provider is registered through webconfig and uses the membership provider interface. It only accepts certain fields in the create function. So what's a boy to do? Well, you can open a larger scale transaction up in your controller, run the membership providers add user function, run your own MyCustomUserStuff(), then commit the transaction. Two reasons I find this unappealing are that I've now got transactional code seeping way up my call stack and if all I need to do is add a few extra fields I've now doubled my database calls needlessly.
I guess I just found the membership provider pretty restricting, and once got in there and made my own custom membership provider the benefits of using MS's model quickly fell away.
Validation
I think the answer here is a resounding --it depends. Are your permissions pretty static? i.e. those in the "SiteManagers" group can edit all over the site? Or are your permissions much more fine grained? Meaning SiteManagers have access to these 75 fields spread across these 22 tables, or is it more table based? Additionally, how mutable are the permissions ? Does your site admin need to be able to frequently turn access on/off or off to various fields in different tables?
I think I need to hear more on your requirements for a specific answer. Keep in mind that the more fine grained you make your permissions the more of a configuration headache the client will have understanding & managing all the permissions.
Also, what back-end are you using? Many DBA's face these decisions. One often used strategy in that world is to create a series of views where each view exposes the columns users have. For example, the EmployeesHR view would expose just those columns that HR people have access to, and the EmployeeDirectory would expose just those fields that the directory has access to.Then HR users are given permission to the HR view, but not the underlying table. Just a thought.
Anyway, hope this helps.
1- Your distinction of the layers seem correct to me.
I wouldn't reference the DAL in the UI, as in my projects, I prefer that only the middle layer access the DAL. But it's not wrong.
So you seem in the right direction.
2- To my knowledge there is no MembershipProvider that works with EF.
So in projects where we used Membership, here is what we did :
created the tables with the aspnet_regsql.exe
configure the Web.Config to use the SqlMembershiptProvider
added in the web.config ANOTHER connection string (one for Membership and one for EF)
Built the EDMX file with all tables, including the Membership ones.
In the code, a UserManager / RoleManager (BLL or DAL it depends on your architecture) get the informations using standard Membership methods. And always use the Membership objects, not EF ones. So in fact the user / roles management part is separated from the EF.
We only use the aspnet_* EF entities when there is a link between your custom tables and a Membership table (for instance, when you want to link one of your table with the aspnet_Users table to keep a reference of the user that inserted a data).
3- For the right management, I would use a BLL RightManager that would allow the UI to know if the user can change the field (so you can disable it, or prevent input), and to use this information in your validation method.
In my project I use a Right table and I associate a Right with a Role. In the RightManager provide a RequestRight(Right) method.
If your Right management is too simple to create tables, just use User.IsInRole() in your RightManager (so I would use it in BLL).
I would place the validation method in the UI if it is "basic" and in the BLL if it contains more complex rules (involving DAL access for instance).
about EF & Membership
as i know, you dont need to use any db provider instead of membership provider
but if you want, you can map membership tables in EF and create additional method to
common provider
I am trying to make an asp.net website using Visual web dev and C# that accesses data in an SQL database. For my site, I need to be able to save and access additional user properties such as age and gender. I have been playing around with the built in .NET Login tools but I don't understand how to keep track of the additional properties (age, gender...) I could store all the users information in my own database but how do I correlate the users data in my DB to the usernames in the member database that is automatically created?
Probably profiles are perfect and quite easy to use for your purpose. ASP.NET manages the relation between users and their associated profile data (which you can customize for your needs) quite comfortable. Here is short introduction video:
http://www.asp.net/learn/videos/video-44.aspx
Are you using an ASP.NET website project or web application project? The video (and most information in MSDN) is related to website projects. For web applications there are some complications to take into account when you use profiles.
(Some hints if you are using a web application project:
How to assign Profile values?
If you are using an website project you can ignore this)
As Slauma said ASP.Net Profiles is a great way to do this using the Membership API.
But I don't like the way profiles use delimited list serialized in the database, and I've heard reports of speed issues under heavy load.
I Use Membership API on just about all applications, except for the profile bit.
To store user profiles, you can create a separate table. Maybe called 'UserProfile'. Add a column with a unique index for 'username' and/or 'email'. Which ever you treat as the user's username. Now you can use that column to pull profile information at runtime.
As a bonus, if you use an ORM like Entity framework, you can now write simple LINQ queries to pull your user information.