I am developing asp.net mvc web application with Entity Framework 6.1.3.
The asp.net identity that comes by default seemed fine to me until my boss said we cannot make any changes to the database tables (users, user roles) to fit with aspnet identity, as it is a legacy db..as is described here: https://www.youtube.com/watch?v=elfqejow5hM
So, what are my options now?
can i totally remove aspnet identity? how?
can i tell my identitycontext that my table names and columns are different and also change the behaviour in rolemanager?
On top of all this, my database is a mysql db Cheers :)
A default ASP.NET MVC project with Individual User Accounts, comes with a middleware named Owin, which in short allows a lot of authentication configs for your app, like:
Cookies Authentication
Cookies External Auth
Two Factor SignIn (e.g a password + code in mobile by sms)
Facebook Authentication
OAuth Bearer Token
etc...
Meanwhile, Identity is a library built to mix various old memberships, thus allowing you to work with many ASP.NET frameworks, such as ASP.NET MVC, WebForms, etc. Moreover, it comes with a built-in implementation, which also works as a provider for owin capabilities. Though, Identity is all based on interfaces, so developers can easily customize anything there, like plugging/unplugging features. This is just a short description.
So, what are my options now?
Use Identity's built-in engine, it'll create new tables for itself (including AspNetUsers and AspNetRoles), which you won't mix with your existing tables. Inside Models folder, there is an IdentityModels.cs file, with an ApplicationDbContext class, inheriting IdentityDbContext. Bring your existing DbSet for your models there (including for the existing user and role). You can create a relationship between the ApplicationUser (which comes by default with a brand new project, representing an IdentityUser) and your existing User. So you won't affect your existing tables at all.
You can implement all Identity's interfaces by your own (not that hard, but it takes some time to understand), then you could make your existing User and Role implement respectively IUser and IRole to combine with Identity.
You can make your existing models for User and Role just inherit IdentityUser and IdentityRole. After this, naturally your ApplicationDbContext would like to insert/update some columns in your tables to fit IdentityUser and IdentityRole models (since your classes now inherit from them), then you might want to configure it to avoid changing your existing tables.
Can i totally remove aspnet identity?
Sure you can. If you don't need all that Owin's features at all, you might not even use it, for sake of simplicity.
How?
You could just create a new project with Forms Authentication rather than Individual User Accounts, and implement a custom RoleProvider to interact with your existing Role. It's kinda easy to implement a custom RoleProvider for forms authentication. You can make your provider check for roles by querying your tables, or consuming a webservice, it's up to you.
Can i tell my identitycontext that my table names and columns are
different and also change the behaviour in rolemanager?
Sure. Override the OnModelCreating method in your ApplicationDbContext (the same one which inherits IdentityDbContext) to change all its default behaviour when generating/updating database. You might not call base.OnModelCreating(modelBuilder);, because this is what creates a lot of configs for your tables.
I suggest you to start reading about ASP.NET Identity and maybe Using MySQL Storage with an MySQL EF Provider, so you can decide whether you keep Identity, customize it, remove it, etc.
Related
With the new version of VS 2013 RTM and asp.net mvc 5.0, I’ve decided to try out a few things...
Needless to say, a lot has changed. For example, the new ASP.NET Identity is a replacement of the old Membership and (less old) SimpleMembership APIs.
In all previous applications I’ve built, I never had the chance to work with Membership or with SimpleMembership. I’ve always ended up creating my own Login() method which would convert a submitted ViewModel to a POCO (using automapper) which in turn, would use some sort of repository to lookup the user and password.
In return, I would obtain a User POCO that would later be converted (using automapper) to a smaller UserSession POCO. The smaller UserSession would be place in Session.
Of course, I would still use FormsAuthentication to create an Encrypted Ticket and use FormsAuthentication.SignOut() when the user wanted to logoff.
But I never fully took advantage of what Membership (or SimpleMembership) had to offer.
I never had my POCOs implement some sort of Interface nor did I have to add a reference to the Microsoft’s libraries inside my POCO class library. In other words, I never had a strong dependency on anything.
My question is the following:
With the examples I see, I keep seeing that the new ASP.NET Identity creates (via code first) some tables and fields. For example, the AspNetUsers table holds an Id field as a string. Of course, I’m sure there is a way to overcome this and will eventually see examples, but why would anyone NOT want to build pure POCO classes and have total control of what and how things are created?
Unless I’m confused (which has a high probability) can anyone explain why I would want to use the new ASP.NET Identity API (or more importantly, use the new Microsoft.AspNet.Identity.EntityFramework) to create my tables?
What are the Pros and Cons in wanting to use this as opposed to the POCO style of things?
Perhaps I should be asking this in a different question, but I’m also trying to understand how can I benefit the new claims-based Identity while using POCOs instead of Entities generated with ASP.NET Identity.
Feel free to point me in the right direction for clarifications.
you can create your own UserManager completely,wich i don't recommand unless you have a strong knowledge about how it works.you can wrap the existing UserManager and make you application rely on an interface or just use it directely and benefit from what microsoft has put in it.if you don't like EF you can create your own Store to use another Database. the new ASP.NET Identity is extensible enough,i agree that is kinda Hard if you want to take full controle and customize everything,but i recommand taking time to understand the most of it so you can choose when to use or not.most of time it's enough to use the existing UserManager.
You want the UserManager from Microsoft.AspNet.Identity to do your security part such your users do not have to trust that you can handle your security information correctly.
Identity.Framework is just a datastore for the Identity stuff, you could create your own store instead if you dont want EF. I have created one that just stores information directly in a xml file. But I always come back to using Identity because I dont want to deal with encrypting and making sure I am up to date with stuff in the security department.
First a background. Our application is built on ASP.NET MVC3, .NET 4.0, and uses Linq-to-Sql (PLINQO) as its primary means of data access. Our web application is a multi-tenant/multi-client system where each client gets their own Sql Server database. Each Sql Server database up to now has had exactly the same schema.
Often times, clients will ask us to track custom fields in their Db that other clients don't track. The way we've handled this is by reserving a number of customfields in the db in our main tables. For example, our Widget table may have a CustomText1, CustomText2.. CustomText10, and a CustomDate1, CustomDate2..CustomDate10 fields. Again, all our schemas across clients are the same, so Linq-to-Sql handles these fields just as easily as any other field.
Now we are running into an issue where a client wants several hundred CustomBool fields, but doesn't need the others. So, basically, we are researching for ways to still use the Linq-to-Sql, but have it work against potentially different schemas depending on the database it is connected to (although they are different in a very specific way.)
Too much code has already been built on Linq-to-Sql and accessing the Widget classes generated by it that I'd like to not just fall back to straight SQL.
I've seen answers here and on the web on ways for Linq to Sql to access different tables that have the same schema, but I have not found a good answer to the same table name across different dbs with different columns.
Is this possible?
If the main objective is to store a few extra fields for existing domain objects then why not create a generic table that can store key value pairs. This is extremely flexible since there is no need to change your schema if a customer requires a new property.
We do this frequently and normally have some helpers to correctly cast the properties e.g.
Service.GetProperty<bool>("SomeCustomProperty")
If you are looking for a more "pluggable" domain model that can be completely different for each tenant, I think you will struggle if you are following a database driven approach and using the L2S designer to generate your code.
To achieve this you really need to be generating your database based on your code (domain driven design) which will give you much more flexibility i.e. you can load a tenant specific configuration (set of classes, business rules etc.) at runtime and use this to generate/validate your schema.
Update
It would be good if you could elaborate on exactly what design approach you have taken i.e. are you using the Linq designer and generating your model from the database?
It's clear that a generic key value pair store is not going to meet your querying requirements.
It's hard to provide a solution without suggesting a different technology. Relational SQL databases aren't really suited for dynamic domain models. You may be better off with a document database such as MongoDb or RavenDb where you are not tied to a specific schema. You could even make use of these just for your custom properties.
If that's not ideal then another solution would be to use something like Dapper to construct your queries. Assuming you are developing against interfaces you can have a implementation of your data service per tenant that makes use of their custom fields.
Ayende did a whole series of posts on Multitenancy and covers tenant specific domain models. It starts here and may be of some use to you.
I am working on an application which acts as a setup box for other child applications. I want to set up child applications from one central parent application. Set up includes database setup (db:create and db:migrate), subdomain set up etc for child apps.
This is going to work like this: a Subscriber will subscribe many applications. On subscription the application will be configured to work on subscribers provided subdomain (on my site). Every instance of a subscribed application will have its own database. So I need to set up database for each subscriber, and domain name too.
Currently I am creating database based on child application subdomain, using ActiveRecord::Base.connection.execute.
After creation of the database I want to load the schema of the child app to the database created. For this I had posted a question here
schema.sql not creating even after setting schema_format = :sql
Is there any good efficient method/approach that will help me?
Also I am a bit confused about subdomaining how its gonna be work?
Any help/thought appreciated...
Thanks,
Pravin
Since there is no real need for a separate database for each user and for each 'app', you may want to check out a term called multi tenant.
Also, subdomains can be handled in rails 3 and use something called Devise for User authentication. Github has a rails 3 sudomain devise authentication fork to get you started.
Until you really see a need for all these databases, keep it simple. One database per application, and connect to each application via Active Resource.
Be warned, that what you are undertaking can confuse even a hardened app builder, so i hope your experience begets that of which your current Stackoverflow rate is at.
All the best.
I'm building an application on top of a legacy database (which I cannot change). I'm using Linq to SQL for the data access, which means I have a (Linq to SQL) class for each table.
My domain model does not match with the database. For example, there are two tables named Users and Employees, and therefore I have two Linq to SQL classes named User and Employee. But in my domain model I'd like to have a User class which should contain some fields from either table (but I don't care about a lot of the other fields of these tables).
I'm not sure how I should design my repositories:
should the repositories perform the mapping between Linq to SQL classes (e.g. User, Employee) to the domain classes (User) and only return the domain classes to the application
or should my repositories return the Linq to SQL classes and leave the mapping to the caller
The first approach seems to make more sense to me, but is this the correct way to implement my repositories?
The purist (I try to stay pure) will tell you that your model represents your data. And therefore, anything that needs to be persisted is done so only when needed through repositories. Also, when you have complex entities, you want to use a service to combine them. For example, User + Employee = UserEmployee entity that is only accessible through an IUserEmployeeService.
With those vague statements, you have an excellent opportunity here.
Build an anti-corruption layer, which allows you to start moving off of the legacy DB at the same time.
This is an another chapter in the DDD playbook. An Anti-Corruption layer is used to interface with a legacy system using Facades, Translators, and Adapters to isolate the legacy DB with your pure Domain model.
Now, this may be a lot more work than you wanted. So, you have to ask yourself at this point:
Do I want to start the process of
moving off of this legacy DB, or will
it remain for the life of the
application?
If your answer is you can start migrating, then model your actual domain the way you want it. Persist it with normal repositories and services. Have fun designing it the way YOU want it stored. Then, use the services of the aggregate roots to reach into the anti-corruption layer and pull out the entities, store/update them locally, and translate into your domain's entities.
If the answer is that the legacy DB will remain for the life of the project, then your task is much easier. Use your domain's services (e.g. UserEmployeeService) to reach into the anti-corruption's UserFacade and EmployeeFacade (similar to a "Remote Service" concept).
Within the Facades, access the legacy db using the Adapters (e.g. LegacyDbSqlDatabase) to get a raw legacyUser(). The next step would be to use an UserTranslator() and EmployeeTranslator() mapper that converts the legacy user data into your actual domain's version of the User() entity, and return it from the UserFacade back to your UserEmployeeService, where it is combined with the Employee entity that came from the same place.
Whoa, that was a lot of typing...
With your Adapters and Facades of your Anti-Corruption layer, you can do your Linq-to-Sql or whatever you want to do. It doesn't matter because you have completely isolated the legacy DB/system away from your nice and pure Domain - your domain that has its own version of User() and Employee() entities and value objects.
DDD and Linq To SQL don't go together very well because the generated classes are not meant to deviate significantly from your DB table structure. You'll have to either map your classes in a way that makes working with Linq to SQL a pain or just live with a non-ideal object model.
If you really want to utilize DDD and the repository pattern go for Entity Framework or even better NHibernate.
First a bit about the environment:
We use a program called Clearview to manage service relationships with our customers, including call center and field service work. In order to better support clients and our field technicians we also developed a web site to provide access to the service records in Clearview and reporting. Over time our need to customize the behavior and add new features led to more and more things being tied to this website and it's database.
At this point we're dealing with things like a Company being defined partly in the Clearview database and partly in the website database. For good measure we're also starting to tie the scripting for our phone system into the same website, which will require talking to the phone system's own database as well.
All of this is set up and working... BUT we don't have a good data layer to work with it all. We moved to Linq to SQL and now have two DBMLs that we can use, along with some custom classes I wrote before I'd ever heard of Linq, along with some of the old style ADO datasets. So yeah, basically things are a mess.
What I want is a data layer that provides a single front end for our applications, and on the back end manages everything into the correct database.
I had heard something about Entity Framework allowing classes to be built from multiple sources, but it turns out there can only be one database. So the question is, how could I proceed with this?
I'm currently thinking of getting the Linq To SQL classes all set for each database, then manually writing Linq compatible front ends that tie those together. Seems like a lot of work, and given Linq's limitations (such as not being able to refresh) I'm not sure it's a good idea.
Could I do something with Entity Framework that would turn out better? Should I look into another tool? Am I crazy?
The Entity Framework does give a certain measure of database independence, insofar as you can build an entity model from one database, and then connect it to a different database by using a different entity connect string. However, as you say, it's still just one database, and, moreover, it's limited to databases which support the Entity Framework. Many do, but not all of them. You could use multiple entity models within a single application in order to combine multiple databases using the Entity Framework. There is some information on this on the ADO.NET team blog. However, the Entity Framework support for doing this is, at best, in an early stage.
My approach to this problem is to abstract my use of the Entity Framework behind the Repository pattern. The most immediate benefit of this, for me, is to make unit testing very simple; instead of trying to mock my Entity model, I simply substitute a mock repository which returns IQueryables. But the same pattern is also really good for combining multiple data sources, or data sources for which there is no Entity Framework provider, such as a non-data-services-aware Web service.
So I'm not going to say, "Don't use the Entity Framework." I like it, and use it, myself. In view of recent news from Microsoft, I believe it is a better choice than LINQ to SQL. But it will not, by itself, solve the problem you describe. Use the Repository pattern.
if you want to use tools like Linq2SQl or EF and don't want to have to manage multiple DBMLS (or whaetever its called in EF or other tools), you could create views in your website database, that reference back to the ClearView or Phone system's DB.
This allows you to decouple your web site from their database structure. I believe Linq2Sql and EF can use a view as the source for an Entity. If they can't look at nHibernate.
This will also let you have composite entities that are pulled from the various data sources. There are some limitations updating views in SQL Server; however, you can define your own Instead of trigger(s) on the view which can then do the actual insert update delete statements.
L2S works with views, perfectly, in my project. You only need to make a small trick:
1. Add a secondary DB table to the current DB as a view.
2. In Designer, add a primary key attribute to a id field on the view.
3. Only now, add an association to whatever other table you want in the original DB.
Now, you might see the view available for the navigation.