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.
Related
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.
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'm going to start a new project which is going to be small initially but may grow to big over the years. I'm strongly convinced that I'm going to use ASP.NET MVC with jQuery for UI. I want to go for MySQL as database for some reasons but worried on few things.
I'm totally new to Linq but it seems that it is easier to use once you are familiar with it.
First thing is that accessing data should be easy. So I thought I should use MySQL to Linq but somewhere I read that it is not directly supported but MySQL .NET connector adds support for EntityFramework. I don't know what are the pros and cons of it. DbLinq is what I also heard. I would love if I can implement repository pattern as it allows to apply filter in logic layer rather than in data access layer. Will it be possible if I use Entity Framework?
I'm also concerned about the performance. Someone told me that if we use Entity framework it fetches lot of data and then filter it. Is that right?
So questions basically are -
Is MySQL to Linq possible? If yes where can I get more details on it?
Pros and cons of using EntityFramework or DbLinq with MySQL?
Will it be easy to access data using EntityFramework or DbLinq with MySQL?
Will I be able to implement repository pattern which allows applying filter in logic layer rather than data access layer (when I use EntityFramework with MySQL)
Does it fetches hell lot of data from database and then apply filter on it?
If it sounds too many questions from my side in that case, if you can just let me know what you will do (with a considerable reason) in this situation as an experienced person in this area, that should answer my question.
As I am fan of ALT.NET I would recomend you to use NHibernate for your project instead of EntityFramework, you may google for the advantages over it, I am convinced you'll choose it.
Based on the points you've mentioned, then I would seriously consider going with MS SQL instead of MySQL initially and implementing LINQ-to-SQL instead of Entity Framework, and here's why:
The fact that you are anticipating a lot of traffic initially tells me that you need to think about where you plan to end up, rather than where to start. I have considerably more experience with MS SQL than I do with MySQL, but if you're talking about starting with the community version of MySQL and upgrading later, you're going to be incurring a significant expense anyway with the Enterprise version.
I have heard there is a version of LINQ that supports MySQL, but, unless things have changed recently, it is still in beta. I am completing an 18-month web-based project that used ASP.NET MVC 1.0, LINQ-to-SQL, JavaScript, jQuery, AJAX, and MS SQL. I implemented the repository pattern, view models, interfaces, unit tests and integration tests using WatiN. The combination of technologies worked very well for me, and I plan to go with the same combination for a personal project I'm developing.
When you get MS SQL with a hosting plan, you typically have the ability to create multiple databases from that single instance. It looks like they give you more storage because they give you multiple MySQL databases, but that's only because the architecture only supports the creation of one database per instance.
I won't use the Entity Framework for my ASP.NET MVC projects, because I wasn't crazy about ADO.NET in the first place. I don't want to have to open a connection, create a command object, populate a parameter collection, issue the execute method, and then iterate through a one-way reader object to get my data. Once you see how LINQ-to-SQL simplifies the process, you won't want to go back either. In the project I mentioned earlier, I have over 60 tables in the database with about 200 foreign key relationships. Because I used LINQ-to-SQL with the repository pattern in my data layer, I was able to build the application using not a single stored procedure. LINQ-to-SQL automatically protects against SQL injection attacks and support optimistic and pessimistic concurrency checking.
I don't know what your project is, but you don't want to get into a situation where you're going to have trouble scaling the application later. Code for the end result, not for the starting point, and you'll save yourself a lot of headaches later.
I am currently reading Pro Asp.Net MVC, and they are building all of their linq2sql entity classes by hand, and mapping them with the linq mapping attributes. However, everyone else I see (from google searches) talking about linq 2 sql seem to be using the visual designer for building all of their entities. Which is the preferred way to build l2s entities, and what are the advantages/disadvantages of each?
The only difference I have noticed so far, is I can't seem to do inheritance mapping when using the visual designer, although MSDN says I should be able to so I might just be missing it in VS 2010's interface. However, I'm not so sure I should use inheritance anyway as that could technically add additional joins when I don't need the sub table data.
As a PS, l2s will not be doing any modification of my schema, I will be generating schema changes manually and then replicating them in linq2sql.
Thanks,
We used the designer all the time. It indeed introduces an added step, every time you make a change to the schema you need to import the table into the designer again, but I think that effrot pales in comparison to the amount of code you need to write if you bypass the desginer.
Also note that the designer creates partial classes, you can create an additional file for the partial class that includes additional implementation details. That way, when the table gets refereshed in the designer, it leaves you additional code alone. We do this to add a lot of helper functions to the classes, and also to provide strictly typed enumerated properties that overlay the primitive integer FK fields.
It's true that inheritance would be very difficult to accomplish well, but I think if you need that sort of data layer, L2S may not be the best solution. I prefer to keep my data layer clean and simple, just using L2S to get the data in and out, and then pu more complicated logic in the business layer. If we really needed to do things like object inheritance in our data layer, I would probably explore a more advanced and complicated technology like EF
We've built our entire application framework backend using L2S. I developed most of the this. I started to use the DBML designer but I quickly realized this was a royal pain. Every schema change required a change to the table(s) in the designers. Plus, the entities created by the designer all get stuffed in a single class file, and didn't have all the functionality I wanted, like support for M2M relationships, and more. So, it didn't take long before I realized I wanted a better way.
I ended up writing my own code generator that generates the L2S entities the way I want them, and it also generates a "lightweight" set of entities that are used in the application layer. These don't have any L2S plumbing. The code generator creates all these entities, and other code, directly from a target database. No more DBML!
This has worked very well for us and our entities are exactly the way we want them, and generated automatically each time our database schema changes.
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.