Implementing A Custom Storage Mechanism

MembershipReboot is designed with a flexible account storage mechanism. You can create your own custom user account data storage mechanism for use with MembershipReboot. The default implementation uses EF and you can swap it out to use your own custom made storage mechanism using somthing like Nhibernate, Simple.Data or a NoSQL implementation for MongoDb or RavenDB.

To do this all you need to do is provide implementation for IUserAccountRepository<T> where T is of type UserAccount. There are two account models, relational model and hierarchical data model represented by the generic RelationalUserAccount<T> and HierarchicalUserAccount classes respectively. MR uses the ID defined in the UserAccount class to uniquely identify an account, this does not mean that it should be used as the primary key when creating the database table. It's solely up to the you to decide how you want it. The default EF implementation uses the RelationalUserAccount which has it's <TKey> - Key declared as int and configures the database to use this key as the primary key, while the MongoDB & RavenDB implementation uses the HierearchicalUserAccount. The UserAccountService which is responsible for all account related operations (e.g creating account, retrieving account details) stores and retrieves account details to the database via the IUserAccountRepository . If you want query capabilities beyond what IUserAccountRepository provides, then you need to provide an implementation for IUserAccountQuery, aside that the only thing you need to implement is the IUserAccountRepository. If your DB supports IQueryable (which not all DB supports) you can use the QueryableUserAccountRepository<T> class instead of the IUserAccountRepository<T>. If you use the abstract QueryableUserAccountRepository<T> class, then you get IUserAccountRepository<T> and IUserAccountQuery because this helper class implements both interfaces.

MembershipReboot also supports groups (some what like roles). This feature is kind of separate from the account features, but an application can use them together. The group's storage mechanism can be customised the same way as the user account. You have the IGroupRepository<T>, IGroupQuery, and QueryableGroupRepository<T> which you can work with.

Having made these changes, you can use dependency injection to specify the actual repository type you need your application to work with. You will find in samples directory, a MongoDb & RavenDB implementation and a sample that utilizes it.