What Design Pattern[s] Are Used In Microsoft.Aspnet.Identity.Core? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 8 years ago.

Improve this question

I'm very curious as to how Microsoft came up with the architecture used in the new Identity Model.

All I know is there are models as interfaces with barebones properties. There are stores (interfaces) for unquestioned/basic data access and storage, and managers (actual classes) which I suppose contain the logic for creating/updating resources (I presume, to avoid duplicate records and other validation).

The "framework" looks like they want us to implement the given models (for custom properties) and the stores (for specifying storage mechanism).

I think this architecture is very useful for building a system with company-specific objects, but I don't know where to look for guidance or any more information on this. What should and shouldn't be done when constructing an architecture similar to Asp.net Identity?

Answer 1

Well I think the best design pattern to describe the UserManager is as a facade for all the various store interfaces. The IUserStoreXXX interfaces were intended to make each of them optional for store implementations, with the idea that the default UserManager would be able to be used safely regardless of the functionality the actual store provides.

The other pattern would be Unit of Work with the implicit expectation for stores to respect this and only save changes inside of the core IUserStore CRUD methods.