Does anyone know a good practice to use when developing for the system.directory services class?

Question

I'm trying to create a data access later using System.DirectoryServices. I'd like to use the MVC 2 framework and have all my views be mostly strongly-typed. Does anyone know any good way to this?

For example I started creating a Group Entity:

public class Group
{
    public string DistinguishedName { get; set; }
    public string GroupName { get; set; }
}

And an abstract interface:

public interface IGroupRepository
{
    List<Group> Groups { get; }
}

I am confused about developing the GroupRepository using the system.directory services. Connecting to a SQL database is easy there are examples everywhere but I have no been able to find any using the System.directory sevices in conjunction with a class using MVC. Has anyone tried to do something like this? Any great would be

Answer 1

If you're on .NET 3.5 (and if you use MVC 2, chances are good you are), you should check out the new System.DirectoryServices.AccountManagement namespace which brings you lots of strong .NET classes and types for many of the directory objects you're dealing with on a regular basis - no need to re-invent the wheel (yet again!).

Check out this great article in MSDN magazine on how to use this S.DS.AM namespace:

Managing Directory Security Principals in the .NET Framework 3.5

Update: for reasons I don't totally understand, the simple approach of using a UserPrincipal as a model for a ASP.NET MVC view doesn't work - it seems as if ASP.NET MVC cannot "find" any properties on that object.

So the approach would have to be to do something like this:

• grab your UserPrincipal (or DirectoryEntry) from Active Directory
• define a separate ViewModel - this is just a class that holds properties, like first name, last name and so forth
• you can either fill that ViewModel class yourself, or you can grab some help like AutoMapper to make mapping from UserPrincipal (DirectoryEntry) to your ViewModel easier
• then display (or edit) your ViewModel class in a standard ASP.NET MVC view
• handle any possible updates by transferring any changes back from the ViewModel to the "proper" object and persisting that object

It's a bit more involved than I'd like it to be - but I quite honestly don't see how else you can do this otherwise.