UserControls with the MVC Framework

Published 3/11/2008 by Henry in C# | Patterns
Tags: ,

When building applications re-using components that contain functionality that is used in more than one place in that application is best practice. More than that it is one of the fundamentals of OO development.

What about with the MVC framework?
Can we use Controls, or UserControls? Because the MVC Framework does not use ViewState, events can not be used, so how do we use these Controls with the MVC Framework?
With the MVC Framework at this moment in time we can use the MVCToolkit, this Toolkit has UIHelpers, with these UIHelpers it is easier to create Textboxes, Dropdownlists, RadioButtons etc in the View.
But what if we have a grid with the same datasource and columns that we need on different Views? How do we go about in creating say a custom 'GridControl' UserControl that we can use on one or more in our MVC Framework application?

Creating a custom Grid UserControl
First we create a new MCV View User Control Item, through a right-click 'Add > New Item...'.  

New MVC View User Control
New MVC View User Control

We name the Control: 'Grid'. Than we open the Code-Behind Grid.cs file and you will see that the UserControl does not inherit System.Web.UI.UserControl, but inherits from System.Web.Mvc.ViewUserControl.
Because we want to show data in a grid, we need a way to let the Control use the same data as the containing ViewPage.
For this purpose we can use (like the System.Web.Mvc.ViewPage) the System.Web.Mvc.ViewUserControl syntax to provide our control with the object that we want to bind the grid to.

   1:  using System;
   2:  using System.Web;
   3:  using System.Web.Mvc;
   4:  using HC.Data.AuditHistory;
   6:  namespace HC.Web.AuditTool.Views.Controls
   7:  {
   8:      public partial class Grid : ViewUserControl<AuditData>
   9:      {
  10:      }
  11:  }
Listing 1

All we have to do now is make sure our grid looks oke and shows the right data in the right place:

   1:  <table cellpadding="0" cellspacing="0" class="ListArea">
   2:      <tr>
   3:          <td id="tdDataArea">
   4:              <table id="gridBodyTable" cellpadding="1" cellspacing="0" class="List-Data">
   5:                  <colgroup>
   6:                      <col class="DataColumn List-SortedColumn"   />
   7:                      <col class="DataColumn"  />
   8:                      <col class="DataColumn"  />
   9:                  </colgroup>                                               
  10:  <% 
  11:      int numberOfRow = 0;
  12:      foreach (var auditHistory in ViewData.AuditHistory)
  13:      {
  14:  %>                                                         
  15:                  <tr class="List-Row">
  16:                      <td class="DataCell">
  17:                          <%=auditHistory.FieldDisplayName%>
  18:                       </td>
  19:                      <td class="DataCell">
  20:                          <nobr >
  21:                              <%=auditHistory.PreData == "" ? "&nbsp;" : auditHistory.PreData%>
  22:                          </nobr>
  23:                      </td>
  24:                      <td class="DataCell">
  25:                          <nobr >
  26:                              <%=auditHistory.UserName%>
  27:                          </nobr>
  28:                      </td>
  29:                  </tr>                                                 
  30:  <%
  31:      }
  32:  %>
  33:              </table>
  34:          </td>
  35:      </tr>
  36:  </table>
Listing 2

Now we open the first ViewPage in designmode and drag and drop the UserControl on the ViewPage. In the ViewPage we also make sure we inherit from ViewPage and use the ViewPage syntax:

   1:  using System.Web.Mvc;
   2:  using HC.Data.AuditHistory;
   4:  namespace HC.Web.AuditTool.AuditTool.Views.Auditing
   5:  {
   6:      public partial class List : ViewPage<AuditData>
   7:      {
   8:      }
   9:  }
Listing 3

In our Controller we fill the ViewData with data and call the View, so the ViewPage loads and holds the ViewData. Next the UserControl is loaded by the ViewPage and it's ViewData is filled by the ViewPage's ViewData.

   1:  using System.Web.Mvc;
   3:  using HC.Data.AuditHistory;
   4:  using HC.Web.AuditTool.Models;
   6:  public class AuditingController : Controller
   7:  {
   8:      [ControllerAction]
   9:      public void Index()
  10:      {
  11:          AuditData auditData = AuditingDataModel.GetAuditData();
  12:          ViewData.Add("AuditHistory", auditData);
  13:          RenderView("List", auditData);
  14:      }
  15:  }
Listing 4

The result is a grid on a web page.
But the beaty is that whenever a view(page) uses the same object for data, the grid will work. 

I hope I made clear that with the MVC Framework we lose ViewState and events, but we can still re-use our Controls, be it in a slightly different way than we are used to.

Henry Cordes
My thoughts exactly...

Unit test controller in MVC Framework

Published 2/9/2008 by Henry in ASP.NET | C#
Tags: ,

I started using the MVC Framework. I wanted to see if it is for me, because I am a big fan of TDD, but with web apps for me at least, it always is a struggle.
After having a bit of a startup problem, I really started to see the point after a while. The decoupling of concerns, with the Controller as entrypoint, that gets the data from a model and hands it over to the View is a really elegant solution.

Model View Presenter
With the MVP pattern (Model View Presenter) the aspx Page was the entrypoint, it delegated the call to the Presenter only to be called again. This is no decoupling.
With MVC the controller is the spider in the web. The greatest advantages I see in this Framework (or designpattern) is:

  • Allows extensive unit testing (use any unit testing framework you want to (MS Test, NUnit, MBUnit, etc).
  • Separation of concerns, all core contracts within the framework are interface based and therefore mockable
  • No more UrlRewriting, you can model your Url's completely(UrlRoutingEngine)
  • Extensible and pluggable (it is possible to use IOC containers like Windsor, Spring.Net, NHibernate, etc)

A picture to show how the project templates look in the Project Explorer, this is how we create an MVCApplication.

New MVC Application Project

By choosing the 'ASP.NET MVC Web Application and Test' projecttemplate, we get a Test project in our solution also. The MvcApplication's structure is structured around folders.
We get a Content folder, where the css file is located. And we get the: Models, Views and Controllers folders.

New Project structure

Also we get a Test Project in the solution. So how do we test a controller, how do we go about in isolating this 'unit' (the controller), so we can really 'unit test' it?

Interface for DataSource
I want to really decouple the controller so I can test only the functionality provided by the controller.

It needs to be possible to switch the real model for a 'test' or 'mock' version, this apllies also to the view. It also must be possible for the view to be 'mocked' like that.  

What I want is a to show a page containing AuditHistory. So I started to create an Interface that defines the DataSource (IAuditHistoryDataSource).

   1:  using System;
   2:  using System.Collections.Generic;
   4:  namespace MvcApplication.AuditInfo
   5:  {
   6:      public interface IAuditHistoryDataSource
   7:      {
   8:          List<AuditHistory> GetAuditHistoryData();
   9:          List<AuditHistory> GetAuditHistoryDataByUserName(string userName);
  10:      }
  11:  }
Code listing 1: 'IAuditHistoryDataSource'

For the applications data I used LINQ to SQL, that allows me to select the database and with the click of a button generating the code to get the data from my database. Of course you can use whatever datasource you want, LINQ to Entities, LINQ to AD, plain old Datasets, ORM created datasources, NHibernate etc.

The name of the LINQ to SQL class is AuditDataContext:

LINQ to SQL Datamodel

The Model gets a private read-only IAuditHistoryDataSource property that is instantiated with a new instance of AuditDataContext when the setter is called while the private variable _DataSource is null.
Using the 'Inversion of Control' or 'Dependency Injection' pattern (which actually is nothing more than paramaterizing the constructor with the object you want the caller to be responsible for). The Model contains only code that calls methods on this IAuditHistoryDataSource Datasource.

   1:  using System;
   2:  using System.Collections.Generic;
   4:  using MvcApplication.Data.AuditHistory;
   6:  namespace MvcApplication.AuditInfo.Models
   7:  {
   8:      public class AuditDataModel
   9:      {
  10:          private IAuditHistoryDataSource _DataSource;
  11:          private IAuditHistoryDataSource DataSource
  12:          {
  13:              get 
  14:              { 
  15:                  if (_DataSource == null)
  16:                  {
  17:                      _DataSource = new AuditDataContext();
  18:                  }
  19:                  return _DataSource;
  20:              }
  21:          }
  23:          /// <summary>
  24:          /// Constructs an instance of AuditDataModel inversing control of the datasource to the caller
  25:          /// </summary>
  26:          /// <param name="dataSource"></param>
  27:          public AuditDataModel(IAuditHistoryDataSource dataSource)
  28:          {
  29:              _DataSource = dataSource;
  30:          }
  32:          /// <summary>
  33:          ///  Gets all AuditItems (by calling a method on the IAuditHistoryDataSource)
  34:          /// </summary>
  35:          /// <returns></returns>
  36:          public List<AuditHistory> GetAuditHistoryData()
  37:          {
  38:              return DataSource.GetAuditHistoryData();
  39:          }
  41:          /// <summary>
  42:          ///  Gets all AuditItems belonging to a particular User with UserName equal 
  43:          ///  to parameter (by calling a method on the IAuditHistoryDataSource)
  44:          /// </summary>
  45:          /// <param name="userName"></param>
  46:          /// <returns></returns>
  47:          public List<AuditHistory> GetAuditHistoryDataByUserName(string userName)
  48:          {
  49:              return DataSource.GetAuditHistoryDataByUserName(userName);
  50:          }
  51:      }
  52:  }
Code listing 2

Using this technique it is now easy to mock the datasource for test purposes. Doing TDD we first write our test, than we write code. To keep this post understandable I choose to write it the other way around. I do not want to bore you with all my mistakes and refactorings, but provide the working solution.
Next I will list the Controller, which like the Model, uses the 'Inversion of Control' or 'Dependency Injection' pattern and takes a IAuditHistoryDataSource as a parameter in its constructor. The Controller than passes this dataSource to the constructor of the Model it uses.

   1:  using System;
   2:  using System.Web;
   3:  using System.Web.Mvc;
   4:  using System.Collections.Generic;
   6:  using MvcApplication.Data.AuditHistory;
   7:  using MvcApplication.AuditInfo.Models;
   9:  namespace MvcApplication.AuditInfo.Controllers
  10:  {
  12:      public class AuditingController : Controller
  13:      {
  14:          private AuditDataModel AuditData;
  16:          public AuditingController()
  17:          {
  18:              AuditData = new AuditDataModel();
  19:          }
  21:          public AuditingController(IAuditHistoryDataSource dataSource)
  22:          {
  23:              AuditData = new AuditDataModel(dataSource);
  24:          }
  26:          [ControllerAction]
  27:          public void Index()
  28:          {
  29:              List<AuditHistory> auditHistory = AuditData.GetAuditHistoryData();
  30:              ViewData.Add("AuditHistoryAll", auditHistory);
  31:              RenderView("List", auditHistory);
  32:          }
  34:          [ControllerAction]
  35:          public void List(string id)
  36:          {
  37:              List<AuditHistory> auditHistory = AuditData.GetAuditHistoryDataByUserName(id);
  38:              ViewData.Add("AuditHistoryByUserName", auditHistory);
  39:              RenderView("List", auditHistory);
  40:          }
  41:      }
  42:  }
Code listing 3

As you can see the MVC Framework uses attributes to define Actions (ControllerAction). The Framework uses these so the right Action (method) is mapped to a url.
Scott Guthrie wrote a couple of blogposts on the subject. He wrote a series of 4 posts, this is part 1:

I want to write tests against the Controller, To do this, first I have to find a way to override the part where the view gets rendered. We do not want to render the view, we want to test if the controller gets the data and passes it to the (right) view.  In the Test project we create a AuditingControllerMock which inherits from the Controller we want to test. In the AuditingControllerMock we override the RenderView method and the only thing we do in it is get the viewName passed in through a parameter and assign it to a property: 'RenderViewAction'.

   1:  using MvcApplication.AuditInfo.Controllers;
   2:  using MvcApplication.Data.AuditHistory;
   4:  namespace MvcApplication.AuditInfo.Test
   5:  {
   6:      public class AuditingControllerMock: AuditingController
   7:      {
   8:          public string RenderViewAction { get; set; }
  10:          public AuditingControllerMock(IAuditHistoryDataSource dataSource):base(dataSource)
  11:          {
  12:          }
  14:          protected override void RenderView(string viewName, string masterName, object viewData)
  15:          {
  16:              RenderViewAction = viewName;
  17:          }
  18:      }
  19:  }
Code listing 4

In the actual Test project I decided to use Rhino Mocks, because it helps me mock the DataSource in just a few lines of code.

   1:  using System.Collections.Generic;
   2:  using Microsoft.VisualStudio.TestTools.UnitTesting;
   4:  using Rhino.Mocks;
   6:  using MvcApplication.Data.AuditHistory;
   7:  using System;
   9:  namespace MvcApplication.AuditInfo.Test.Controllers
  10:  {
  12:      /// <summary>
  13:      ///  This is a test class for AuditingControllerTest and is intended
  14:      ///  to contain all AuditingControllerTest Unit Tests
  15:      ///</summary>
  16:      [TestClass()]
  17:      public class AuditingControllerTest
  18:      {
  19:          /// <summary>
  20:          ///A test for Index, needs to return all items in list
  21:          ///</summary>
  22:          [TestMethod()]
  23:          public void AuditingController_Get_All_AuditHistory_items_IndexTest()
  24:          {
  25:              MockRepository mocks = new MockRepository();
  27:              IAuditHistoryDataSource mockDataSource = mocks.CreateMock<IAuditHistoryDataSource>();
  28:              List<AuditHistory> auditHistoryList = GetBaseTestList();
  30:              AuditingControllerMock controller = new AuditingControllerMock(mockDataSource);
  31:              Expect.Call(mockDataSource.GetAuditHistoryData()).Return(auditHistoryList);
  33:              mocks.ReplayAll();
  34:              controller.Index();
  35:              mocks.VerifyAll();
  37:              Assert.IsNotNull(controller.ViewData["AuditHistoryAll"], "Controller AuditHistoryAll returned null");
  38:              Assert.IsTrue(((List<AuditHistory>)controller.ViewData["AuditHistoryAll"]).Count > 0, 
  39:                              "AuditHistoryAll did not return expected number of items AuditHistory Count is not greater than 0");
  41:          }
  43:          /// <summary>
  44:          ///A test for List(userName), returns all AuditHistory belonging to a particular user
  45:          ///</summary>
  46:          [TestMethod()]
  47:          public void AuditingController_Get_AuditHistory_By_UserName_ListTest()
  48:          {
  49:              MockRepository mocks = new MockRepository();
  51:              IAuditHistoryDataSource mockDataSource = mocks.CreateMock<IAuditHistoryDataSource>();
  52:              List<AuditHistory> auditHistoryList = GetBaseTestList();
  54:              AuditingControllerMock controller = new AuditingControllerMock(mockDataSource);
  55:              Expect.Call(mockDataSource.GetAuditHistoryDataByUserName(UserNameToTest)).Return(auditHistoryList);
  57:              mocks.ReplayAll();
  58:              controller.List(UserNameToTest);
  59:              mocks.VerifyAll();
  61:              Assert.IsNotNull(controller.ViewData["AuditHistoryByUserName"], "Controller AuditHistoryByUserName returned null");
  62:              Assert.IsTrue(((List<AuditHistory>)controller.ViewData["AuditHistoryByUserName"]).Count > 0, 
  63:                              "AuditHistoryByUserName did not return expected number of items AuditHistory Count is not greater than 0");
  64:          }
  67:          private Guid UserIDToTest = new Guid("aa6d5659-fd41-44f1-b838-8c88b0b753e6");
  68:          private Guid ObjectIDToTest = new Guid("1b884382-d51a-4b42-a1f0-d1d1b1adc864");
  69:          private int ObjectTypeToTest = 1;
  70:          private string UserNameToTest = "Bill";
  72:          private List<AuditHistory> GetBaseTestList()
  73:          {
  74:              List<AuditHistory> auditHistoryList = new List<AuditHistory>
  75:              {
  76:                  GetAuditHistory(UserNameToTest,
  77:                                   UserIDToTest,
  78:                                   "Test operation",
  79:                                   ObjectTypeToTest,
  80:                                   ObjectIDToTest,
  81:                                   DateTime.Now,
  82:                                   "Audit data to test"),
  83:                  GetAuditHistory(UserNameToTest,
  84:                                   UserIDToTest,
  85:                                   "Test operation 2",
  86:                                   ObjectTypeToTest,
  87:                                   ObjectIDToTest,
  88:                                   DateTime.Now,
  89:                                   "Audit data 2 to test"),
  90:                  GetAuditHistory(UserNameToTest,
  91:                                   UserIDToTest,
  92:                                   "Test operation 3",
  93:                                   ObjectTypeToTest,
  94:                                   ObjectIDToTest,
  95:                                   DateTime.Now,
  96:                                   "Audit data 3 to test")
  97:              };
  98:              return auditHistoryList;
  99:          }
 101:          private AuditHistory GetAuditHistory(string userName,
 102:                                               Guid userId,
 103:                                               string operation,
 104:                                               int objectType,
 105:                                               Guid objectId,
 106:                                               DateTime modifiedOn,
 107:                                               string auditData)
 108:          {
 109:              AuditHistory audit = new AuditHistory();
 110:              audit.AuditData = auditData;
 111:              audit.AuditID = Guid.NewGuid();
 112:              audit.ModifiedOn = modifiedOn;
 113:              audit.ObjectId = objectId;
 114:              audit.ObjectType = objectType;
 115:              audit.Operation = operation;
 116:              audit.UserId = userId;
 117:              audit.UserName = userName;
 119:              return audit;
 120:          }
 121:      }
 122:  }
Code listing 5

In both tests I create a Mock of the Datasource by passing the IAuditHistoryDataSource to the CreateMock method of Rhino Mocks. I assign a filled List of Type AuditHistory to the variable auditHistoryList with the following line:

   52:  List auditHistoryList = GetBaseTestList(); 
Code listing 6

Next I tell Rhino Mock what method it needs to expect to be called and what that method must return, with the line:

   55:  Expect.Call(mockDataSource.GetAuditHistoryDataByUserName(UserNameToTest)).Return(auditHistoryList); 
Code listing 7

With the next three lines we tell Rhino Mocks it needs to pay attention(line 1. In line 2 we call the ControllerAction 'List' on our Controller. In line 3 Rhino Mocks Verifies if all our assertions are being met:

   57:  mocks.ReplayAll();
   58:  controller.List(UserNameToTest);
   59:  mocks.VerifyAll();
Code listing 8

After that I check if the returned data in the View is not null and if the number of items in the List of type AuditHistory is greater than 0.

My conclusion is that the testability indeed is lots better with the MVC Framework. There is a learning curve, it seemed a bit strange to use the 'classic ASP' way of 'spagetthi coding' in the html, but the separation of concerns is really a big advantage, that not only provides better testing but also better maintainable code.
If the server controls are obsolete now is too much to say, but teams that will use this Framework are going to have to learn another way of working and cannot use the server controls we got used to.
I really want to try out the MVC Toolkit, which provides UIHelpers and otherstuff that is usefull when using the MVC Framework, I did not get the change to work with it, but when I do I hope to post about it here.

MVC Framework links: 
ASP.NET Forum on MVC Framework 

Henry Cordes
My thoughts exactly...

LINQ to Active Directory

Published 1/20/2008 by Henry in C# | LINQ
Tags: ,

Because I needed a way to get users from Active Directory to sync them with another application (CRM). I started out writing Directory Services (LDAP) Queries. I started thinking: "Can't this be done with LINQ?", after all in C# and the .NET Framework 3.0, 3.5  we now have the Language Integrated Query possibilities in our programming toolkit. With LINQ you should be able to query all collections, as long as they impement the IQueryable interface. So why not Active Directory?
When you search: "LINQ to AD" with Google. You''ll find the following link:

Bart de Smet is a belgian developer, who works for Microsoft. He is the one that made LINQ to AD. Here is a serie blogposts he wrote about this topic.
LINQ to AD is a query provider for LINQ that's capable of talking to Active Directory (and other LDAP data sources potentially) over LDAP.
Ofcourse LINQ To AD is a wrapper around System.DirectoryServices.

He wrote the BdsSoft.DirectoryServices.Linq, the LINQ to AD implementation, if you want to use LINQ To AD you need to add a reference to this assembly and you need to reference the Active DS Type Library (ActiveDs.dll). The 'activeds.dll' is a module that contains functions and object methods, or COM components, for the Active Directory Services Interfaces (ADSI) API.

One of the reasons System.DirectoryServices is so powerfull, is because you can still access native ADSI interfaces by using the NativeObject method. NativeObject will return the IADs interface of the specific type of object.
To use the NativeObject method, you'll need to add a reference to the ActiveDs.dll library. I need to get all users belonging to a particular AD Group and sync these to my application.
All I need to do is: Add a reference the BdsSoft.DirectoryServices.Linq assembly and the Active DS Type Library (ActiveDs.dll).
Next I created a method that must Retrieve all users member of a group in the Active Directory.

The method will have two parameters:

  1. domain, a string that will hold the Active Directory domain name
  2. groupName, a string that will contain the name of the group in AD the users belong to

The method will return a List of type User, User is a custom object that represents a user and is called: "RetrieveADUsersInGroup";

Here a listing of the signature: 

   1:  private List<User> RetrieveADUsersInGroup(string domain, string groupName)
   2:  {
   3:      // Put code here
   4:  }
Listing 1

In the method, an instance of the System.DirectoryServices.DirectoryEntry object needs to be instantiated.
I pass a string to the constructor ('LDAP://'), so the DirectoryEntry instance is bound to the node in Active Directory Domain Services that is located at this specific path.

   1:  DirectoryEntry rootOfDirectory = new DirectoryEntry(string.Format("LDAP://{0}", domain));
Listing 2

Now we take this DirectoryEntry object (rootOfDirectory) and pass it to the constructor of the object DirectorySource<T> (which implements the IQueryable<T> interface), together with the enum System.DirectoryServices.SearchScope (defines the scope for a Directory search).
We take SearchScope.Subtree, which means the whole SubTree, including Base object and all child objects.

Here the signature of the method that is called and lives inside the BdsSoft.DirectoryServices.Linq assembly. 

   1:  public class DirectorySource<T> : IQueryable<T>, IDirectorySource
   2:  {
   3:      // Code here
   4:  }
Listing 3

Now we use the keyword: 'var', var is a way to declare variables in C# 3.0  and up, that uses implicit typing. Keep in mind that var is not the same as 'object', or the JavaScript 'var' datatype as it’s actually strongly typed, but inferred from whatever the value is being assigned.
The proces of creating datatypes on the fly is called: 'projection'. Var is projecting the datatype from the Query.

   1:      var groups = new DirectorySource<Group>(rootOfDirectory, SearchScope.Subtree);
   2:      var listOfAllGroups = from          grp in groups
   3:                            where         grp.Name == groupName
   4:                            select new {  grp.Name, MemberCount = grp.Members.Length, grp.Members };
Listing 4

On line 1 'var groups' the complete root directory is inferred as BdsSoft.DirectoryServices.Linq.DirectorySource<T>, where 'T' is of type 'ActiveDirectory.Group', my own class that represents an ActiveDirectory group. 
From line 2 on the LINQ syntax is used to get all groups from the Collection where the name is equal to the value in methods string parameter 'groupName'. From these groups or group the Name, MemberCount and Members are taken and returned by the query and assigned to the listOfAllGroups variable.

I wanted to map the result from this LINQ Query directly to my User type, instead of needing to loop through every result and map each property one by one. What provides an opportunity to show that you can map your own types to the Query's result, after all you can predict the projection result. 
First the code that retrieves the users: 

   1:  var UserFromAD = new DirectorySource<Centric.PublieksDiensten.KC.ActiveDirectory.Entities.User>(rootOfMemberDirectory, SearchScope.Subtree);
   3:  IEnumerable<User> usersFromQuery = from adUser in UserFromAD
   4:                                     select new User
   5:                                     {
   6:                                          Firstname = adUser.FirstName,
   7:                                          Lastname = adUser.LastName,
   8:                                          AccountName = adUser.AccountName,
   9:                                          Email = adUser.Email,
  10:                                          PhoneNumber = adUser.TelephoneNumber,
  11:                                          Fax = adUser.Fax,
  12:                                          AddressStreet = adUser.AddressStreet,
  13:                                          City = adUser.City,
  14:                                          State = adUser.State,
  15:                                          Country = adUser.Country
  16:                                      };
Listing 5

On line 3 the variable 'usersFromQuery' is of type 'IEnumerable of type User' (IEnumerable<User>). IEnumerable needs to be implemented if we do not want to use 'var'. On line 4 the part 'select new' is extended to 'select new User' in this way we project our own User type. In the body of the Query you see every field is mapped to a property of the User type through field name/value pairs. Under the covers var infers the field names, field values, and field data types and creates an anonymous type with the fields we project.


  • IEnumerable of type ...
  • select new ...
  • map through field name/value pairs

Here a listing with the complete code from the Method:

   1:  private static List<User> RetrieveADUsersInGroup(string domain, string groupName)
   2:  {
   3:      DirectoryEntry rootOfDirectory = new DirectoryEntry(string.Format("LDAP://{0}", domain));
   5:      var groups = new DirectorySource<Group>(rootOfDirectory, SearchScope.Subtree);
   6:      var listOfAllGroups = from          grp in groups
   7:                            where         grp.Name == groupName
   8:                            select new {  grp.Name, MemberCount = grp.Members.Length, grp.Members };
  10:      List<User> userList = new List<User>();
  12:      foreach (var currentGroup in listOfAllGroups)
  13:      {
  14:          foreach (var member in currentGroup.Members)
  15:          {
  16:              DirectoryEntry rootOfMemberDirectory = new DirectoryEntry(GetLDAPPath(domain) + "/" + member);
  17:              var UserFromAD = new DirectorySource<Centric.PublieksDiensten.KC.ActiveDirectory.Entities.User>(rootOfMemberDirectory, SearchScope.Subtree);
  19:              IEnumerable<User> usersFromQuery = from adUser in UserFromAD
  20:                                          select new User
  21:                                          {
  22:                                              Firstname = adUser.FirstName,
  23:                                              Lastname = adUser.LastName,
  24:                                              AccountName = adUser.AccountName,
  25:                                              Email = adUser.Email,
  26:                                              PhoneNumber = adUser.TelephoneNumber,
  27:                                              Fax = adUser.Fax,
  28:                                              AddressStreet = adUser.AddressStreet,
  29:                                              City = adUser.City,
  30:                                              State = adUser.State,
  31:                                              Country = adUser.Country
  32:                                          };
  34:              userList.AddRange(usersFromQuery);
  35:          }
  36:      }
  38:      return userList;
  39:  }
Listing 6

LINQ is a layer of abstraction over the way we query data. It is in the case of LINQ to AD a nice beginning to get rid of the LDAP Querying. LINQ overall provides a way to query Databases, Collections, Active Directory, XML and every Datasource for that matter in the same way from now on. In the LINQ to AD case the fact that had to query all groups and then loop through these groups to get the members of the groups is a big shortcoming. I had hoped to have to write one query that did all the work and returned a list of users. Still because the datasource is DirectoryServices and Active DS I can understand that their limits are in the way of making this possible. Still I hope in the future this will be possible.
I do like to work with LINQ and will try to learn more about it's inner workings. I definitely see a shift in paradigm, no more static language only in C# and I think change like this is exiting!

Henry Cordes
My thoughts exactly...

Microsoft Press have just released an e-book on Visual Studio 2008 technologies and are giving it away for free. The e-book includes excerpts from three recent book releases and provides a wealth of information and insights from top experts:

Look here

Henry Cordes
My thoughts exactly...

Wallpaper: C# Programmers do it better

Published 4/6/2007 by Henry in C# | Fun
Tags: ,

Today I had a creative urge, so I made a wallpaper with the subject C#.
This is the wallpaper:


Feel free to take and use.

Henry Cordes
My thoughts exactly...