I have to have my security in a different database, because multiple applications use the same security database.
I want to be able in one of my models in a project to reference a user virtually. I can't do this however, since it would create a foreign key relationship over different databases, which is impossible.
I also have a common configuration database where several applications use the same config tables, and have the same problem for the same reason.
What's my best move in this situation?
Thank you.
Related
i have ASP.NET website with ASPNETDB.MDF database from default providor.
i have also MainDB.MDF that contains all other site database.
i want to combine ASPNETDB.MFD into MainDB.MDF in order to have only one DB.
is it possible?
if yes what are the disadvantages of this combination?
The only theoretical disadvantage is that you may want to run several apps with shared users. Then it would be better to have external provider. Most people don't do that of course then it is better to have data and users in the same database to make deployment and backup easier.
To achieve this just run the asp.net regsql tool against your database and it will create the tables. Then have just one connection string to your database and you are done.
I heard it is not a good idea to bring in the tables created by the aspnet_regsql.exe into your entity model. Can they just be removed from the model or is it a better idea to have it in a separate database?
The default is to create an "aspnetdb" database separate from your application database. You can name the database whatever you like, but having a separate Application Services database is the best practice. It isolates your user store and prevents any conflicts from occurring between it and any other database.
Furthermore, you want to use the classes included with the .Net Framework to interact with your Application Services database; it has its own data access layer separate from your EF classes. You don't want to use EF to work directly on the database, so it makes more sense to separate them.
The tables create with that tool are for the asp providers and used by them. If you use those tables in you model you run the risk of modifying data that the providers would not expect. If you remove them from your model you will remove this risk. You could potentially still modify the data via Execute() but personally I do not see a problem with them being in the same database.
I have three different applications, they all share the ASP.NET membership aspect of the database and almost definitely they won't share anything else.
Should I have a separate database for each of the applications, or would one suffice?
All the application tables are prefixed, so that wouldn't be a problem in integration. Although I was wondering if there would be any performance issues, or if having all three applications share the same database would be some kind of grave mistake.
The applications in question are three web applications, the "main site", a forum and a bug tracker. I'm wondering if this is viable because integration could be easier if I had a single database. For instance, the bug tracker registers asp.net membership tables in it's db connection, and it even creates an "admin" user, where the db that is actually supposed to be holding the membership tables would be the "main site" one.
Update: I added a bounty to this question since the answers seem to have pretty split opinions about whether I should or not use multiple databases for different applications that share only membership providers.
Separate apps = separate databases - unless you have to "squeeze" everything into a single DB (e.g. on a shared web hoster).
Separate databases can be backed up (and restored!) separately.
Separate databases can be distributed onto other servers when needed.
Separate databases can be tweaked individually.
I have always found it would be better to have more databases so that it is easier to:
Migrate to more servers if needed
Manage security / access easier
Easier (and Faster) restores and backups
I would actually go with four databases. A Membership database, and then one for each application (if the membership is truly shared). This will allow you to lock security across applications as well.
Looking at your question closer... You say that the data would "likely not be shared"... will a lot of your queries be joining tables with the membership? If so, might be easier if they are in the same database. However if you are going with a more entity based approach, I would think you would still be better with multiple databases. You might even want to look at something like an LDAP database or some other type of caching for your membership database to speed things up.
You should use the same database unless you have a current need to place them in separate databases - HOWEVER where possible you should architect your system so that you could move the data into a separate database should the need arise.
In practise this means that you should keep SQL procedures working the smallest amount of data possible - i.e. Don't have multi-step stored procs which do lots of separate actions. Have separate usps and call each from code.
Reasons to use separate databases:
1) Unrelated data - Group data that is interrelated - andonce databases get beyond a certain complexity, look to separate out blocks of related data into separate databases in order to simplify.
2) Data that is of either higher importance (e.g. Personal Details) should be separated to allow for greater security measures: e.g. screening this data from developers
3) or lower importance (e.g. Logging Info) - this probably does not need backing up - and if it's particularly volumous, you probably don't want it increasing the time taken to back up the main site database.
4) Used by applications living on different servers at different locations. Quite obviously you want to site data as close as possible to the consuming application.
Without really knowing the size and scale of your system, difficult to give full opinion, if it's just your own site, one db may work for now - if it's commercial then i'd have 4 dbs from the word go: Membership details, Forum, Bug Tracker and MainSite related stuff.
Thus in code you would have a Membership manager which only talks to the Membership db, A BugManager, A ForumManager and anything else will only talk to the MainSite db. I can't think of any reason you'd need any of these databases talking to each other.
Just my inclination: although the three apps might not share much (not yet, anyway: but what happens when a forum post wants to reference a bug report?), they all belong to the same "system," so to speak.
I would definitely put all of the tables in just one database.
In my opinion , it is better to split the database for increased flexibility, security, efficiency, and scalability.
In future if there is any addition of requirement (you never know) which is common to all the three applications , it might be a little difficult to maintain.
For example: User login /audit trace for your 3 applications.
It may sound like I'm wandering a bit, but have you taken into account another possibility, that is separating all the authentication/membership functionality into an application itself?
From your description it seems you may add another application in the future. It would start to look like a network of sites, much like 37signals web apps, Google web apps or MSN web apps.
And thus, you may go for a kind of Single-Sign-On / Connect service. This one single application may offer authentication methods via web-services or any other mechanisms, it will have its own DB for you to tweak, modify, backup and move without affecting the other apps. I myself have found this situation many times and thus I love how easy is to share your Google or Facebook login among applications.
Perhaps I'm seeing it from a little higher perspective than yours, sorry if it's the case. If this is not an option, you may keep 4 databases: 1 for each application and 1 for the membership provider, which has its own connectionstring most of the time.
Of course it depends on the size of your applications' footprint on DB-level. 10 tables per app is OK, 150 tables per app would make the DB a little ugly to us, that being a personal preference.
Good luck with whatever option you choose.
The membership framework allows for partitioning across multiple applications, so you probably should have the following configuration:
Membership Database
Application 1 Database
Application 2 Database
Application 3 Database
Then, in each of the application databases, create synonyms that point to the membership database's tables for when you need to write your own queries that access both application data and membership data. Synonyms are easy to maintain and allow you change where the database is without changing any dependencies on those tables as the synonym names don't change.
Your application configuration in Web.config will determine how the data is partitioned in the membership database as you specify an ApplicationName that should be different for each app.
in my web site i have two databases, ASPNETDB.MDF and a self created one (database.mdf). (The don't contain a lot of data yet)
But i need a relationship (foreign key) between a table in ASPNETDB.MDF and a table in database.mdf.
So i guess i need to merge both databases first, would you just extend the "ASPNETDB.MDF" with the tables from "database.mdf" ?
or better configure "database.mdf" for the asp.net Applicatoin Services and then delete "ASPNETDB.MDF" ?
Is "ASPNETDB.MDF" even meant to be used in a production online web application?
(Right now i'm using sql server express but i will probably use sql server when deploying Site to a shared host)
thanks a lot for answers
the scripts for the structure that is inside ASPNETDB.MDF are deployable on a different database (http://msdn.microsoft.com/en-us/library/x28wfk74.aspx)
however, I would really consider wether or not you want to do a foreign key to those tables, the membership, roles and profile API is intended to be used as a pluggable API, something you will break by defining your foreign key
Setting up membership in existing database is something you should be looking at. If you are asking me, I will and I have created membership related data objects in my application specific database. You can find the SQL scripts to do so at C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727(v4.0.30319 in case you have VS 2010).
By doing this you can create foreign keys to membership table and achieve your objective.
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