Building a mongodb provider for the new ASP.NET Identity framework - Part 2 RoleStore And Sample

Several people have requested help understanding how to use the MongoDB provider in a real application. Turns out there's a sample available as a NuGet package Microsoft ASP.NET Identity Samples.

The sample works with EntityFramework. I took the sample, and commit by commit adapted it to use the MongoDB provider. Checkout the modified sample.

One thing the sample had, that the mongodb provider had not yet implemented was a RoleStore. I hesitated to add this to the mongodb provider simply because I don't run across too many use cases for dynamic roles in an application. When I do see this, it's often very custom to the application and providing a generic means to handle this isn't that valuable. With that said, I went ahead and added a simple implementation if someone wants to see how this works with the identity sample and how they may want to adapt it for their own application.

One of the design decisions in doing this was not to update user documents when roles are deleted and when role names were updated. Instead of trying to provide an implementation for unknown use cases, I decided to make the RoleStore operations virtual so they could be extended by consumers. I had a couple of thoughts I wanted to share:

  • I intended the original implementation of the roles array on user documents to store role names.
  • When a role is deleted, leaving the role on the user document shouldn't be a problem. Yes it's orphaned data, but this is the world of denormalized data and is typical when working with NoSQL databases. If that won't work in your use case, consider a multi update to remove the role from user documents.
  • When a role name is changed, you may or may not need to update user documents. If you just made a mistake in the process of setting up a new role, no big deal if it's not yet assigned to any users. This is the use case I targeted. If you're renaming a role after it's been in use, you'll need to modify the user documents accordingly. You could override the RoleStore's UpdateAsync to do this before the role is renamed, just be aware that there's no easy way to ensure consistency of this operation across documents.
  • If you want to avoid issues with renaming roles, you could store the id of a role, instead of the name, in the user document's roles array.



Pluralsight Course: Using MongoDB with ASP.NET MVC

After months of hard work, I've finished my first Pluralsight course! I labored to distill what I've learned about MongoDB, specifically within the .NET platform, to help others get a jump start. My favorite part was sharing how document databases remove many of the constraints that usually hamper good design within our applications.

Using MongoDB with ASP.NET MVC

Interested in using MongoDB to store information in your ASP.NET MVC applications? This course covers the decisions you will face and the tools available to incrementally build an MVC application with MongoDB. You will learn how to connect to MongoDB using the official C# driver, create documents and customize serialization, overcome the object relational impedance mismatch and start creating rich domain models, store and modify documents, query documents with both LINQ and Mongo query styles, and store files with GridFS. At the end of this course, you will have the skills necessary to begin using MongoDB in your .NET applications.


Video: The Value of Consistently Formatted Code

Tabs or Spaces, the age old debate that will likely never be settled! Fortunately, at the end of the day consistent formatting is more valuable than the rules we follow because consistency significantly improves readability and maintainability.


Wallowing In Ideas

Anyone involved in software development is keenly aware there's never a shortage of ideas. Sometimes ideas are on the scale of a multi month development endeavor. Often they're just a small tweak to existing software. The trouble is, ideas are customarily acted upon without a second thought. The waste is debilitating.

Ideas alone are merely a possible course of action. Without a framework to discern impact, the focus shifts to efficiently cranking out the first thing that comes to mind to see what happens. If we shift the focus to potential impact we'd get the fastest feedback about whether an idea is wise or foolish, faster than the fastest automated delivery pipeline.

Describing impact in terms of tangible and intangible value spotlights many ideas as worthless. Worthless because the cost would exceed the value, the value is not well understood, or the impact was never defined.

The first time I worked on a project where impact was the focus and potential value was tangibly defined I had no doubt about what I was doing. Ideas came from a clear understanding of the problem. Ideas had a purpose. And it didn't take many ideas to obtain the value.

Take a sampling of your recent work. Do you know the potential impact? What about the tangible value?

Imagine what it would be like if we generated ideas with a knowledge of the desired impact!

Why don't we empower everyone with a knowledge of the desired impact, including developers? Why do we have so many layers of indirection to transmit ideas when it would be simple to directly communicate desired impact?


Use Regulation As A Reason To Improve The Delivery Of Software, Not Impede It

Hot off the press, a new paper describing how to Use Regulation As A Reason To Improve The Delivery Of Software, Not Impede It


I'm an ineta speaker, use this form to request a speaking engagement.

INETA Community Speakers Program