Proper separation for membership provider & model code

Question

I've got a user management application that includes a membership provider and an associated user model that inherits from MembershipUser. Things work, but I'm not certain I'm leveraging things just right. Where should the separation of concerns lie in what code is implemented in the model (like loading an object) versus GetUser from the membership provider?

My thought towards the architecture is that I should be putting as much that's specific to the provider (in this case the LDAP back end) and leaving business rules and whatnot in the model. This, in theory, would allow me to switch to AD by just changing the provider.

This approach seems a little fragmented though. Ideas?

Answer 1

You shouldn't put your load logic in the model. I'd recommend you look into the repository pattern.

http://martinfowler.com/eaaCatalog/repository.html

There's a video about it here: http://www.asp.net/learn/mvc-videos/video-351.aspx