Best way to structure classes for accounts (Active Directory, Gmail, etc.) in C#

I'm starting to develop a set of classes t开发者_运维知识库o house account information. I need to perform CRUD operations on a number of different types of accounts (Active Directory, Google Apps, and others). I am trying to design the classes properly to start with so that they conform to OO principles and they are flexible for the future.

To give you a bit of background, I am maintaining and updating user accounts in our proximity card system, our Active Directory, our Google Apps account, and possibly a few others in the future. Each system has a different way of doing things but they do have similarities. I want to create an interface that I can code against in a way that I can drop in new account classes down the road without major changes.

The problem is that I think I might need two classes for each type of account. One class should hold the user information (for example, first name, last name, etc.) However, I need a way to find a user in each system. At first I thought of putting the FindUser method inside the class. That would work if we were only returning one user. However, I may ask for all the users with a first name of "Tom". That might return five users. I wouldn't want one class spawning four more instances of itself because I wouldn't know where to store them. My thought, then, would be to have a class with the methods that stores one or more instances of a class that contains just the data.

For instance, in Active Directory, I would have the following basic structure:

MainClass:
FindUser()
FindUsers()
List<ADUsers>

ADUsers:
_firstName
_lastName
_userName
_etc.

Thus, the MainClass would be used to perform the FindUser/s methods and the users could be accessed through the list.

The other option would be to have the MainClass FindUser method return an instance of the ADUsers class and the FindUsers method return a List of ADUsers.

My question is, is this the right way to approach this overall problem? Don't forget that I have to expand this to handle all different types of user systems. The above example would end up being my basic interface that I would extend for more complex cases.

Writing the actual code itself is not my issue (it is almost all done). My issue is laying it out properly in an intelligent design. Your help there would be much appreciated. As for language specifications, I am writing this in C#.

I wouldn't put a find method in each type of user, objects should be unaware of their persistence. Instead why not treat things as a repository? You'd have something like

IUserRepository<T>
  public T Create()
  public T Load(object identifer);
  public void Save(T user);

etc. And then have an interface for a base user;

IUser
  public object Identifier { get }
  public string Email { get }

etc. and implement concrete versions for an AD User, a Google Apps user etc, and matching repositories. You could use the factory pattern to return the right type of repository according to your configuration or whatever else you like?

Preface: I'm familiar with LDAP and ADSI. Just read some specs about Google Contacts Data API. I only worked with cards on the very low level, using e.g. PKCS#11 API, so most likely I know nothing about the cards API you're using.

My opinion on the topic is: there's too much difference to try to hide that difference behind an abstraction layer. They have different query languages. Even the e-mail is stored differently: in AD you have the single "mail" sttribute, in google contacts you've got the array of structures, with 1 mandatory and 4 optional fields in each of them. Google API is stateless HTTP request/response, ADSI/LDAP is statefull session-based.

Maybe if I had more information about what your smart card API, and the functional requirements for the system you're designing, I'd come up with something more clever.