Overview of the service layer

Everything starts from an interface called IRequestHandler:

public interface IRequestHandler 
{
  Response HandleRequest(Request request);
}

Request and Response are empty base abstract classes:

public abstract class Request {}
public abstract class Response {}

Now let’s define a simple rule: every concrete request type must be corresponded by a concrete response type. The idea is to basically consider each service operation as a request which must have a response. For each request you define, you need to provide an handler which does whatever it needs to do to handle the request and returns a response. In my solution, a simple generic base request handler has been defined in the following way:

public abstract class RequestHandlerBase<TRequest, TResponse> : IRequestHandler 
                                                              where TRequest : Request 
                                                              where TResponse : Response 
{
    public Response HandleRequest(Request request)
    {
        return HandleRequest((TRequest)request);
    }

    public abstract TResponse HandleRequest(TRequest request);
}

For example, by inheriting this RequestHandlerBase base class, we could create a login request handler, which implements the business logic for validating a user:

public class LoginRequestHandler : RequestHandlerBase<LoginRequest, LoginResponse>
{
    public override LoginResponse HandleRequest(LoginRequest request)
    {
      // validate the user credentials contained in the LoginRequest 
      // and return a LoginResponse containing, for example, a session token 
    }
}

Having each request handler implemented in the same fashion as the LoginRequestHandler, I’d like to reach a service implementation like this:

public class MyService : IRequestHandler 
{
    private readonly IRequestHandlerProvider _requestHandlerProvider;

    public MyService(IRequestHandlerProvider requestHandlerProvider)
    {
        _requestHandlerProvider = requestHandlerProvider;
    }

    public Response HandleRequest(Request request)
    {
        return _requestHandlerProvider.GetRequestHandler(request.GetType()).HandleRequest(request);
    }
}

As you can see, the service itself implements the IRequestHandler interface and the actual implementation is very minimal: it’s just a small class which resolves the appropriate handler through an abstraction called IRequestHandlerProvider which internally may use an IoC container capable of resolving the request handler associated to a request type. Then, the service delegates the execution to an handler by passing the request to it, and finally it returns a typed response to the client.

Enter MEF

Now we could need a IoC container to resolve and create the instances of the request handlers. As shown in this post, you can use the Castle Windsor IoC container to use dependency injection. That basically allows you to register each valid request handler that is present, for example, in a given assembly. Even my purpose was to find a simple way to plug in request handlers defined in external assemblies, getting everything registered automatically in a centralized request handler provider when the application starts up. So, I was focused on MEF. What I tried to do is to treat each request handler as an extension, because in my project each tuple “Request-Response-Handler” represents an extension unit. Moreover,

• MEF is an integral part of the .NET Framework 4
• MEF offers a set of discovery approaches for locating and loading available extensions even in a “lazy” fashion
• MEF allows tagging extensions with additonal metadata which facilitates rich querying and filtering so an extensibility element can provide metadata to exported items.

Following this philosophy, beyond the classic Export attribute I introduced a RequestHandlerMetadataAttribute useful for simplifying the process of resolving an handler related to a specific request type. So, the LoginRequestHandler defined before could be decorated as the following…

[Export(typeof(IRequestHandler))] // I am a request handler!!!
[RequestHandlerMetadata(typeof(LoginRequest))] // I can handle Login requests!!!
public class LoginRequestHandler : RequestHandlerBase<LoginRequest, LoginResponse>
{
  ... 
}

And here is the RequestHandlerMetadataAttribute definition.

public interface IRequestHandlerMetadata 
{
    Type RequestType { get; }
}

[MetadataAttribute]
[AttributeUsage(AttributeTargets.Class, AllowMultiple = false)]
public class RequestHandlerMetadataAttribute : ExportAttribute 
{
    public Type RequestType { get; set; }

    public RequestHandlerMetadataAttribute(Type requestType)
        : base(typeof(IRequestHandlerMetadata))
    {
        RequestType = requestType;
    }
}

In order to allow us to access the metadata, MEF introduces a special kind of Lazy<T,M> that has attached metadata. M in this case is an interface (called “metadata view”) that contains only getter properties. MEF automatically generates a proxy class that implements this interface and it plugs all the metadata in for us. This is very cool! What is happening behind the scenes is that MEF is using reflection emit in order to construct the typed metadata view.

As result, I’ve used the metadata view IRequestHandlerMetadata to easily find the right handler for a request of a given type, as shown in the GetRequestHandler() method of the following MefRequestHandlerProvider.

public class MefRequestHandlerProvider : IRequestHandlerProvider 
{
    private readonly List<Lazy<IRequestHandler, IRequestHandlerMetadata>> _registeredHandlers =
                                              new List<Lazy<IRequestHandler, IRequestHandlerMetadata>>();

    public MefRequestHandlerProvider(IEnumerable<ComposablePartCatalog> catalogs)
    {
        foreach (var catalog in catalogs)
        {
            var container = new CompositionContainer(catalog);
            var exportedHandlers = container.GetExports<IRequestHandler, IRequestHandlerMetadata>();

            foreach (var exportedHandler in exportedHandlers)
            {
                foreach (var registeredHandler in _registeredHandlers)
                {
                    if (registeredHandler.Metadata.RequestType == exportedHandler.Metadata.RequestType)
                        throw new NotSupportedException(string.Format("A request handler for type {0} is already registered.",
                                                                      exportedHandler.Metadata.RequestType));
                }
            }

            _registeredHandlers.AddRange(exportedHandlers);
        }
    }

    public IRequestHandler GetRequestHandler(Type requestType)
    {
        var handler = _registeredHandlers.SingleOrDefault(r => r.Metadata.RequestType == requestType);
        if (handler != null) return handler.Value;
        throw new RequestHandlerNotFoundException(string.Format("No request handler has been found for type {0}", requestType));
    }
}

Putting all together, in the application startup I placed the following initialization code which uses the MefRequestHandlerProvider. As you may know, request handlers can be located inside catalogs (e.g. AssemblyCatalog, AggregateCatalog etc.). When using a client proxy, I need to expose just one method which never needs to be updated. That’s a good advantage!

// Server-Side 
var catalog = new AssemblyCatalog(typeof(IRequestHandler).Assembly);
var mefRequestHandlerProvider = new MefRequestHandlerProvider(new[] { catalog });
MyService service = new MyService(mefRequestHandlerProvider);

// Client-Side (when using a proxy)
LoginResponse response = (LoginResponse)serviceProxy.HandleRequest(new LoginRequest("username", "password"));
Console.WriteLine(response.AccessToken);

Conclusion

In this post I’ve tried to show how I used MEF to plug request handlers in a request/response service layer similar to Agatha. I have not written anything about serialization issues when exposing the service layer through WCF. Moreover, I haven’t treated any aspects about request handlers such as objects lifecycles or error management. I think that any question about these service layer insights can find good answers after reading the Davy Brion’s Request/Response Service Layer Series.

HTH

What’s Identity Map?

In Martin Fowler’s book “Patterns of Enterprise Application Architecture”, the Identity Map is defined as a way of ensuring “that each object gets loaded only once by keeping every loaded object in a map. Looks up objects using the map when referring to them.”  If the requested data has already been loaded from the database, the identity map has to return the same instance of the already instantiated object and if it has not been loaded yet, it should load it and stores the new object in the map. In this way, it follows a similar principle to lazy loading. As result, the Identity Map design pattern introduces a consistent way of querying and persisting objects (e.g. through a context-specific in-memory cache) which prevents applications from duplicate retrievals of the same object data from the database.

Ok, in order to better understand this concept, let’s start from a non-Identity Map example. If we have an application that uses a simple persistence layer that performs a database query and then materializes one or more objects, we might see code that creates different instances of the same logical entity:

[TestMethod]
public void Non_IdentityMap_Solution_Provides_Different_Copies_Of_The_Same_Customer()
{
    Customer customer1 = DAL.Customers.GetCustomerById("dsantarelli");
    Customer customer2 = DAL.Customers.GetCustomerById("dsantarelli");

    // customer1 and customer2 should represent the same customer...         
    Assert.AreEqual(customer1.CustomerId, customer2.CustomerId);
    Assert.AreEqual(customer1.Email, customer2.Email);

    // ... but they are two separate instances!     
    Assert.IsFalse(customer1 == customer2);

    // If we change a property of customer1... 
    customer1.Email = "xxx@yyy.zzz";

    // ... then, which instance should be valid?  
    Assert.AreNotEqual(customer1.Email, customer2.Email);
}

In this example, customer1 and customer2 both contain separate copies of the data for the same customer. If we change the data in customer1, the change has no effect on customer2. If we make changes to both and then save them back to the database, one just overwrites the changes of the other. That’s because our persistence framework just doesn’t know that customer1 and customer2 both contain data for the same logical entity.

Conclusion: multiple objects containing data for the same entity, lead to concurrency problems when it’s time to save data.

How does Entity Framework approach the Identity Map pattern?

Now let’s have a look at the Identity Map way! In the unit test below, we have some Entity Framework code in which three different object queries are executed in order to get data for the same customer:

[TestMethod]
public void EF_IdentityMap_Solution_Provides_References_To_The_Same_Instance_Of_Customer()
{
    using (EFContext context = new EFContext())
    {
        Customer customer1 = context.Customers.Single(c => c.CustomerId == "dsantarelli");
        Customer customer2 = context.Customers.Single(c => c.Email == "dario@santarelli.com");
        Customer customer3 = context.Customers.First(c => c.ContactName == "Dario Santarelli");

        // The three queries above should return the same customer.  
         // So, customer 1,2 and 3 are references to the same instance of Customer. 
        Assert.IsTrue(customer1 == customer2);
        Assert.IsTrue(customer2 == customer3);

        // Now if we change a property of customer1... 
        customer1.Email = "xxx@yyy.zzz";

        // ... then customer 1,2 and 3 still remain valid references to the same instance of Customer. 
         Assert.AreEqual(customer1.Email, customer2.Email);
        Assert.AreEqual(customer2.Email, customer3.Email);
    }
}

How you can see, now all 3 customers are equal. Moreover, when we change a property on customer1, we get that same change on customer2 and customer3. In fact, they’re all references to a single object that is managed by the EF’s ObjectContext. Behind the scenes EF ensures that only one entity object is created and the multiple entities that we try to load are just multiple references to that one object, regardless of how many times or how many different are the ways we load an entity. This is a behavior compliant with the Identity Map pattern!

The key is EntityKey

So how does this work?  First of all, every entity type has a key that uniquely identifies that entity.

If your Customer entity inherits from EntityObject (which is the base class for all data classes generated by the Entity Data Model tools) or simply implements the IEntityWithKey interface, in the debugger you’ll notice that Customer has a property that EF created for you named EntityKey (which corresponds to the primary key in the database). EntityKey contains data about all the information ObjectContext needs in order to maintain an Identity Map. You could think of the map as a “cache” that contains only one instance of each object identified by its EntityKey.

REMEMBER: Entity Framework v4 does not require you to implement IEntityWithKey in a custom data class especially if you use POCO entities.

In the previous example, when we get customer1 from our context, by default EF runs the query, creates an instance of Customer (uniquely identified by its key CustomerId), stores that object in the cache, and gives us back a reference to it. When we get customer2 from the context, the context does run the query again and pulls data from our database, but then it sees that it already has a customer entity with the same EntityKey in the cache so it throws out the data and returns a reference to the entity that’s already in cache. The same thing happens for customer3.

So how many database queries EF will perform if we write something like this?

Customer customer1 = context.Customers.Single(c => c.CustomerId == "dsantarelli");
Customer customer2 = context.Customers.Single(c => c.CustomerId == "dsantarelli");
Customer customer3 = context.Customers.Single(c => c.CustomerId == "dsantarelli");

The answer is: three.

Wait… if there’s a cache, why is it performing three queries? The second part of Martin Fowler’s definition of Identity map says “… looks up objects using the map when referring to them”. An obvious question is: if I’m loading an object that already exists in my cache, and EF is just going to return a reference to that cached object and throw away any changes it gets from the database query, can’t I just get the object directly from my cache and skip the database query altogether? That could really reduce database load.

The answer is: you could explicitly get an entity directly from the cache without hitting the database, but only if you use a special method to get the entity by its EntityKey. Here an example:

EntityKey entityKey = new EntityKey("EFContext.Customers", "CustomerId", "dsantarelli");

object customerObj;
if (context.TryGetObjectByKey(entityKey, out customerObj))
{
    // the customer has been found in the cache Customer customer = (Customer)customerObj;
}

What about if we don’t know the actual value of an EntityKey? Well, we can’t use this feature.

In fact, having to use the EntityKey is a big limitation since most of the time you want to look up data by some other field and not by a primary key which could be a Guid or another data type impossible to know.

Identity Map and MergeOptions

Now two interesting questions:

Can I customize the strategy that EF uses to compare the datasource values and the cache entities values?
What happens to cached entities when the underlying database rows change?

Suppose to have the following code:

Customer customer1 = context.Customers.Single(c => c.CustomerId == "dsantarelli");
// Now someone changes the customer1 record in the DB!!! 
Customer customer2 = context.Customers.Single(c => c.CustomerId == "dsantarelli");

After customer1 is loaded, someone changes the record in the DB. Will customer2 have the original values, or the new values? Remember that customer1 and customer2 are references to the same entity object in the cache, and our first db hit when we got customer1 did pull the original value, but then the query for customer2 also hit the database and pulled data. How does EF handle that? The answer is: it depends on the MergeOption enumeration. The possible options are:

AppendOnly (default) : It simply throws the new data out. If an object is already in the context, the current and original values of object’s properties in the entry are not overwritten with data source values. The state of the object’s entry and state of properties of the object in the entry do not change and Identity Map is guaranteed. Here’s a test example:

[TestMethod]
public void EF_AppendOnly_MergeOption_Throws_NewData_Away()
{
    using (EFContext context = new EFContext())
    {
        context.Customers.MergeOption = MergeOption.AppendOnly;

        Customer customer1 = context.Customers.Single(c => c.CustomerId == "dsantarelli");
        Assert.AreEqual(customer1.ContactName, "Dario Santarelli");

        // Now someone changes the customer1 record in the DB
        // by setting ContactName = "Luigi Santarelli" !!!
        ChangeDBRecord("dsantarelli" , "Luigi Santarelli");

        Customer customer2 = context.Customers.Single(c => c.CustomerId == "dsantarelli");

        Assert.IsTrue(customer1 == customer2); // They are references to the same Customer instance (Identity Map)
        Assert.AreEqual(customer2.ContactName, "Dario Santarelli");  // Original values win! }
}

OverwriteChanges: Unlike the AppendOnly option, it applies new data. If an object is already in the context, the current and original values of object’s properties in the entry are overwritten with data source values, ignoring every changes we make in the meanwhile. Identity Map principle is still preserved.

[TestMethod]
public void EF_OverwriteChanges_MergeOption_Applies_NewData()
{
    using (EFContext context = new EFContext())
    {
        context.Customers.MergeOption = MergeOption.OverwriteChanges;

        Customer customer1 = context.Customers.Single(c => c.CustomerId == "dsantarelli");
        Assert.AreEqual(customer1.ContactName, "Dario Santarelli");

        // Now someone changes the customer1 record in the DB 
        // by setting ContactName = "Luigi Santarelli" !!! 
        ChangeDBRecord("dsantarelli" , "Luigi Santarelli");

        customer2 = context.Customers.Single(c => c.CustomerId == "dsantarelli");

        Assert.IsTrue(customer1 == customer2); // They are references to the same instance (Identity Map) 
        Assert.AreEqual(customer2.ContactName, "Luigi Santarelli"); // New values win }
}

NoTracking : In this scenario, objects are not tracked in the ObjectStateManager. Each time we hit the DB for getting a customer, the EF provides a new instance of the Customer class. So, in this case, the Identity Map principle is broken (we can find some analogies with the non-Identity Map solution presented at the beginning of this post).

[TestMethod]
public void EF_NoTracking_MergeOption_Applies_NewData_And_Provides_Different_Copies_Of_The_Same_Customer()
{
    using (EFContext context = new EFContext())
    {
        context.Customers.MergeOption = MergeOption.NoTracking;

        Customer customer1 = context.Customers.Single(c => c.CustomerId == "dsantarelli");
        Assert.AreEqual(customer1.ContactName, "Dario Santarelli");

        // Now someone changes the customer1 record in the DB
        // by setting ContactName = "Luigi Santarelli" !!!
        ChangeDBRecord("dsantarelli", "Luigi Santarelli");

        Customer customer2 = context.Customers.Single(c => c.CustomerId == "dsantarelli");

        Assert.IsFalse(customer1 == customer2); // They are NOT references to the same instance (NO Identity Map) 
        Assert.AreEqual(customer1.ContactName, "Dario Santarelli"); // customer1 has original values 
        Assert.AreEqual(customer2.ContactName, "Luigi Santarelli"); // customer2 has new values }
}

PreserveChanges : this option is quite a compromise between the AppendOnly and the OverwriteChanges options.

• If we don’t change any property of our entity (i.e. the state of the entity is Unchanged), the current and original values in the entry are overwritten with data source values. The state of the entity remains Unchanged and no properties are marked as modified.
• If we change a property of our entity (i.e. the state of the entity is Modified), the current values of modified properties are not overwritten with data source values. The original values of unmodified properties are overwritten with the values from the data source.
• Entity Framework v4 compares the current values of unmodified properties with the values that were returned from the data source. If the values are not the same, the property is marked as modified.

So, let’s see this behavior in a test…

[TestMethod]
public void EF_PreserveChanges_MergeOption_Preserves_Client_Changes()
{
    using (EFContext context = new EFContext())
    {
        context.Customers.MergeOption = MergeOption.PreserveChanges;

        Customer customer1 = context.Customers.Single(c => c.CustomerId == "dsantarelli");
        Assert.AreEqual(customer1.ContactName, "Dario Santarelli");

        customer1.ContactName = "Carlo Santarelli"; // We change the ContactName in memory

        // Now someone changes the customer1 record in the DB
        // by setting ContactName = "Luigi Santarelli" !!!
        ChangeDBRecord("dsantarelli", "Luigi Santarelli");

        Customer customer2 = context.Customers.Single(c => c.CustomerId == "dsantarelli");

        Assert.IsTrue(customer1 == customer2); // They are references to the same instance (Identity Map) 
        Assert.AreEqual(customer2.ContactName, "Carlo Santarelli"); // Our changes are preserved! }
}

HTH

[TestMethod]

public void MyStyle_Should_Be_Loaded()

{           

  ResourceDictionary dictionary = new ResourceDictionary();

  dictionary.Source = new Uri(“pack://application:,,,/TestClassLibrary;component/ResourceDictionary.xaml”,

                              UriKind.RelativeOrAbsolute);

  object style = dictionary["myStyle"];

  Assert.IsNotNull(style);

  Assert.IsTrue(style is Style);
…

}

… I received the following strange error while trying to instantiate the Uri class…

System.UriFormatException: Invalid URI: Invalid port specified.

But why?
The answer is not so obviuos. That’s because I was executing that code while the pack:// scheme wasn’t yet registered. In fact, this scheme is registered when the Application object is created. The very simple solution is to execute the following code just before executing the test…

[TestInitialize] 

public void OnTestInitialize() 

{   

   if (!UriParser.IsKnownScheme("pack")) new System.Windows.Application();

} 

HTH

Let’s assume to have a base ViewModel useful for editing and saving an object of your model. If the object class is subject to some derivations, maybe you’d like to derive your base ViewModel too in order to fulfill the model inheritance hierarchy. Moreover, most probably you have to define different editing views taking into account the whole inheritance hierarchy. In that case, maybe you’d like to reuse more XAML as possible.

So, let’s assume to have a base abstract Customer class and some concrete specializations, like EducationCustomer and GovernmentCustomer (see image below).   Then, we design ViewModels in order to edit concrete instances of Customer class. In the class diagram below you can see a base ItemEditViewModel<T> which consists in a simple generic ViewModel which exposes a generic Item to be modified and a SaveCommand to persist it somewhere. The class also defines an abstract method OnCanSaveItem() which a concrete implementation must override in order to specify its own validation rules.  

public abstract class CustomerEditViewModel<T> : ItemEditViewModel<T> where T : Customer
{
 public CustomerEditViewModel(T customer) : base(customer) { }
 public CustomerEditViewModel() { } 

 protected override bool OnCanSaveItem() 
 {
 if (Item == null)  return false; 
 return (!string.IsNullOrWhiteSpace(Item.Name) && !string.IsNullOrWhiteSpace(Item.Email)); 
 } 
}

public class EducationCustomerEditViewModel : CustomerEditViewModel<EducationCustomer> 
{
 public EducationCustomerEditViewModel() : base() { }
 public EducationCustomerEditViewModel(EducationCustomer customer) : base(customer) { } 

 protected override bool OnCanSaveItem() 
 {
 if (!base.OnCanSaveItem()) return false;
 else return (!string.IsNullOrWhiteSpace(Item.SchoolName)); 
 } 
}  

public class GovernmentCustomerEditViewModel : CustomerEditViewModel<GovernmentCustomer>
{
  public GovernmentCustomerEditViewModel() : base() { }
  public GovernmentCustomerEditViewModel(GovernmentCustomer customer) : base(customer) { }

  protected override bool OnCanSaveItem()
  {
   if (!base.OnCanSaveItem()) return false;
   else return (!string.IsNullOrWhiteSpace(Item.AgencyName));
  }
}

Ok, we have just defined model and viewmodels. Now the interesting part! Our datatemplates could share some portions of XAML (e.g. the edit DataTemplate of the GovernmentCustomer is quite identical to the DataTemplate of the EducationCustomer, but it differs from the former just for a field). So, how can we reuse DataTemplates? First, we can define the edit DataTemplate for the base Customer class…

<DataTemplate x:Key="customerEditTemplate" DataType="{x:Type m:Customer}">

  <Grid>

    ...

    <TextBlock Text="Name" ... />

    <TextBox Text="{Binding Path=Name, Mode=TwoWay}" ... Background="AliceBlue" />

    <TextBlock Text="Email" ... />

    <TextBox Text="{Binding Path=Email, Mode=TwoWay}" ... Background="AliceBlue" />

  </Grid>

</DataTemplate>

 
and then, we can reuse the XAML above in the edit DataTemplate for the GovernmentCustomer and the EducationCustomer.

<DataTemplate x:Key="governmentCustomerEditTemplate" DataType="{x:Type m:GovernmentCustomer}">

  <StackPanel>

    <ContentPresenter ContentTemplate="{StaticResource customerEditTemplate}" />

    <Grid>

    ...

     <TextBlock Text="Agency" ... />

     <TextBox Text="{Binding Path=AgencyName, Mode=TwoWay}" ... Background="LightPink" />

   </Grid>

  </StackPanel>

</DataTemplate>

<DataTemplate x:Key="educationCustomerEditTemplate" DataType="{x:Type m:EducationCustomer}">

  <StackPanel>

    <ContentPresenter ContentTemplate="{StaticResource customerEditTemplate}" />

    <Grid>

      ...

      <TextBlock Text="School" ... />

      <TextBox Text="{Binding Path=SchoolName, Mode=TwoWay}" ... Background="Yellow" />

    </Grid>

  </StackPanel>

</DataTemplate>

 
OK, that’s all. Finally, a simple view can be implemented as below…

<Window ...>

  <Window.Resources>

    <m:GovernmentCustomer x:Key="governmentCustomer" />

    <m:EducationCustomer x:Key="educationCustomer" />

    <vm:GovernmentCustomerEditViewModel x:Key="governmentCustomerEditVM" Item="{StaticResource governmentCustomer}" />

    <vm:EducationCustomerEditViewModel x:Key="educationCustomerEditVM" Item="{StaticResource educationCustomer}" />

  </Window.Resources>

  <StackPanel DataContext="{StaticResource governmentCustomerEditVM}" Margin="10">

    <ContentPresenter Content="{Binding Path=Item}" ContentTemplate="{StaticResource governmentCustomerEditTemplate}" />

    <Button Content="Save"Command="{Binding Path=SaveItemCommand}"... />

  </StackPanel>

</Window>

 
As you can see, in this example the edit DataTemplate is referenced by key, but in a real scenario you can define your own mechanism to bind the right ViewModel to a DataTemplate for the Item to be edited and saved. In this example, the output result is the following

HTH

If you don’t know this feature of Windows CE, first of all you should read this MSDN article:

Point-to-Point Message Queues with the .NET Compact Framework.

After analyzing the managed wrapper proposed by the article, I’ve started to refactor the source code in order to make it more suitable for my needs. So, I’d like to share my design and implementation .

Let’s explain some key concepts:

• A message queue can be addressed by a name or, generally, by an handle. The handle is the only data you can refer to if the queue has no name (NULL). Note that the empty string is considered a valid, non-null name.
• A message queue can be read-only or write-only: it means that a process can get an handle to a message queue just for reading or writing messages. If you want to read from and write to the same queue, you should create two handles pointing to the same queue.
• Message queues are FIFO. Writers can write messages in a queue until it’s full and readers can read messages from a queue until it’s empty. When a reader process invokes a read operation on a message queue, the first unread message is removed from the queue and delivered to the reading process.

As you can see in the class diagram above, I’ve defined an abstract MessageQueue class which holds the queue info ( e.g. the max length, the max message length, the current readers/writers count and so on… ) and exposes a generic factory method for creating concrete implementations.

public static T Create<T>(string name) where T : MessageQueue
public static T Create<T>(string name, int length) where T : MessageQueue
public static T Create<T>(string name, int length, int maxMessageLength) where T : MessageQueue

Let’s have a look to them:

WriteOnlyMessageQueue

It’s a concrete class for writing messages in a queue. The class exposes some overloads of the Write() method in order to write a message in a queue and choose whether to block the calling thread until the message is written in the queue (that is the queue is not full).

// Create or open an infinite user-defined write-only MessageQueue
WriteOnlyMessageQueue writeOnlyMessageQueue = MessageQueue.Create<WriteOnlyMessageQueue>(“MyQueueName”);

Message message = new Message(UTF8Encoding.UTF8.GetBytes(“Hello world!”));

// WRITE OPTIONS
// 1. block the current thread until a message can be written into the queue (that is the queue is not full).
writeOnlyMessageQueue.Write(message, true);

// 2. block the current thread for a max of 200 ms. If the message can’t be written during this interval, throw an exception.
try { writeOnlyMessageQueue.Write(message, 200); } catch (Exception ex) { }

// 3. don’t block the current thread. If a message can’t be written immediately, throw an exception.
try { writeOnlyMessageQueue.Write(message, false); } catch (Exception ex) { }

ReadOnlyMessageQueue

It’s a concrete class for reading messages from a queue. The class exposes some overloads of the Read() method in order read a message from a queue and choose whether to block the calling thread until a message can be read from the queue (that is the queue is not empty).

// Create or open an infinite user-defined read-only MessageQueue
ReadOnlyMessageQueue readOnlyMessageQueue = MessageQueue.Create<ReadOnlyMessageQueue>(“MyQueueName”);
Message message = null;

// READ OPTIONS
// 1. block the current thread until a message can be read from the queue.
message = readOnlyMessageQueue.Read(true);

// 2. block the current thread for a max of 200 ms. If no message has been read during this interval, throw an exception.
try { message = readOnlyMessageQueue.Read(200); } catch (Exception ex) { … }

// 3. don’t block the current thread. If a message can’t be read immediately, throw an exception.
try { message = readOnlyMessageQueue.Read(false); } catch (Exception ex) { … }

AutoReadOnlyMessageQueue

It’s a concrete class derived from ReadOnlyMessageQueue. It uses a monitoring thread useful to automatically read messages after they are written in the queue. So, the class exposes a MessageRead event which is fired for each message read from the queue.

// Create or open an infinite user-defined read-only MessageQueue
AutoReadOnlyMessageQueue autoReadOnlyMessageQueue = MessageQueue.Create<AutoReadOnlyMessageQueue>(“MyQueueName”);

// Starts monitoring the queue.
// New messages will be read automatically and notified through the MessageRead event.
autoReadOnlyMessageQueue.Start();
autoReadOnlyMessageQueue.MessageRead += (s, e) => { byte[] messageBytes = e.Message.Bytes; }; 

Another static method exposed by the MessageQueue class is OpenByHandle().  It allows you to open a  MessageQueue by using its handle. This method is suitable to open unnamed queues.

public static T OpenByHandle<T>(IntPtr queueHandle) where T : MessageQueue
public static T OpenByHandle<T>(IntPtr queueHandle, IntPtr processHandle) where T : MessageQueue

As you can see, in this case you need an handle to a source process that owns the message queue, while the queue handle is the same returned by the Create() method.
Finally I’ve created a simple smart device project for testing this class library (Visual Studio 2008 / Framework 2.0 or 3.5) just refactoring the example proposed by the author of the MSDN article mentioned above.

You can download source code here.

Here’s a screenshot:

HTH

<%= Html.EditorFor(model => model.BirthDate, “Date”) %>

…or like this…

<%= Html.EditorFor(model => model.EventDateTime, “DateTime”) %>

…then this post may help you. As you should know, in ASP.NET MVC 2 the default model binder has some difficulties to combine splitted datetime parts in the View. So, if you need to define a DateTime property in your model and make a custom editor template that splits the DateTime parts in different controls (e.g. TextBox and/or DropDownList), first you should read this smart solution by Scott Hanselman. The idea is to separate the way we render the month field, the day field, the year field etc. from the mechanism that will assemble them back in a DateTime structure for model binding.
Starting from the Global.asax, the first thing to do is to register the Scott’s Custom Model Binder and then specify all the available options (the strings there are the suffixes of the fields in your View that will be holding the Date, the Time, the Day etc.)

ModelBinders.Binders[typeof(DateTime)]  = new DateTimeModelBinder()
{
  Date = "Date", // Date parts are not splitted in the View
                 // (e.g. the whole date is held by a TextBox  with id “xxx_Date”)
  Time = "Time", // Time parts are not  splitted in the View
                 // (e.g. the whole time  is held by a TextBox with id “xxx_Time”)
  Day = "Day",  
  Month = "Month",
  Year = "Year",
  Hour = "Hour",
  Minute = "Minute",
  Second = "Second"
};

Now, let’s have a look to template editors. In Views\Shared\EditorTemplates directory we can put two simple templates: Date.ascx and DateTime.ascx. The former renders only the drop-down lists for the date part of the DateTime structure (Month, Day, Year), while the latter renders the time part too. Here the code for Date.ascx:

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl<System.DateTime>" %>
<%@ Import Namespace="System.Threading" %>

<%= Html.DropDownListFor(dateTime => dateTime.Month, Enumerable.Range(1, 12).Select(i => new SelectListItem                          
{                              
  Value = i.ToString(),                              
  Text = Thread.CurrentThread.CurrentUICulture.DateTimeFormat.GetMonthName(i),                             
  Selected = (i == Model.Month && Model != DateTime.MinValue && Model != DateTime.MaxValue)                         
}),"-- Month --")%>  /

<%= Html.DropDownListFor(dateTime => dateTime.Day, Enumerable.Range(1, 31).Select(i => new SelectListItem                          
{                              
  Value = i.ToString(),                              
  Text = i.ToString(),                             
  Selected = (i == Model.Day && Model != DateTime.MinValue && Model != DateTime.MaxValue)                         
}), "-- Day --")%> /

<%= Html.DropDownListFor(dateTime => dateTime.Year, Enumerable.Range(DateTime.Now.Year-110, 110).Select(i => new SelectListItem                           
{                                                             
  Value = i.ToString(),                               
  Text = i.ToString(),                              
  Selected = (i == Model.Year && Model != DateTime.MinValue && Model != DateTime.MaxValue)                          
}), "-- Year --")%>

<%= Html.HiddenFor(dateTime => dateTime.Hour)%>
<%= Html.HiddenFor(dateTime => dateTime.Minute)%>
<%= Html.HiddenFor(dateTime => dateTime.Second)%>

That’s all!
Note that in the template editor above, the Hour, Minute and Second parts are rendered as HTML hidden fileds, because the Scott’s DateTimeModelBinder configured in the Global.asax expects a value for all the six parts of the splitted DateTime structure. It’s just a clean workaround to make the Scott’s model binder work without any change to the original code. In a real implementation hidden fields should be not required .

Now, what about validation? Well, both client-side and server-side validations are quite trivial: the server-side validation can be obtained through a custom ValidationAttribute that checks if the DateTime value is correct (e.g. the value should be not equal to DateTime.MinValue or DateTime.MaxValue).

[AttributeUsage(AttributeTargets.Field | AttributeTargets.Property, AllowMultiple = false, Inherited = true)]
public sealed class DateRequiredAttribute : ValidationAttribute
{       
   public DateRequiredAttribute() : base() { }

   public override string FormatErrorMessage(string name)
   {
     return string.Format(CultureInfo.CurrentUICulture, ErrorMessageString, name);
   }
  public override bool IsValid(object value)
   {
     DateTime dateTime = (DateTime)value;
     return (dateTime != DateTime.MinValue && dateTime != DateTime.MaxValue);           
   }
}

The corresponding client-side validation adapter can be implemented by deriving the DataAnnotationsModelValidator class. It allows us to specify a remote validation rule from the client. In this scenario, the part of the DateTime structure that could be validated is the Date part.
So, we can create a SplittedDateRequiredValidator in order to check if each drop-down is holding a valid value. To accomplish this requirement, a simple solution is to make the client-side validator aware of the IDs of the <select> elements holding the DateTime’s Month, Day and Year values.

public sealed class SplittedDateRequiredValidator : DataAnnotationsModelValidator<DateRequiredAttribute>
{
   private string _message;
   private string _dayField;
   private string _monthField;
   private string _yearField;

   public SplittedDateRequiredValidator(ModelMetadata metadata, ControllerContext context, DateRequiredAttribute attribute)
                                        : base(metadata, context, attribute)
   {
      _message = attribute.ErrorMessage;
       _dayField = metadata.PropertyName + "_Day";
       _monthField = metadata.PropertyName + "_Month";
       _yearField = metadata.PropertyName + "_Year";           
   }

   public override IEnumerable<ModelClientValidationRule> GetClientValidationRules()
   {
      ModelClientValidationRule rule = new ModelClientValidationRule
      {
         ErrorMessage = _message,
         ValidationType = "splittedDateRequiredValidator"               
      };

      rule.ValidationParameters.Add("dayFieldId", _dayField);
      rule.ValidationParameters.Add("monthFieldId", _monthField);
      rule.ValidationParameters.Add("yearFieldId", _yearField);

      return new[] { rule };
   }
}

Before looking at javascript validator code, let’s register the SplittedDateRequiredValidator as the client-side validation adapter for all model properties decorated with the DateRequiredAttribute. To accomplish that, we have to put the following line of code in the Global.asax…

DataAnnotationsModelValidatorProvider.RegisterAdapter(typeof(DateRequiredAttribute), typeof(SplittedDateRequiredValidator));

Finally, the client-side validator will evaluate the selected index of the drop-down lists in order to ensure that the user has selected a valid date (note that the isValidDate function simply checks if the users has specified an existing date).

Sys.Mvc.ValidatorRegistry.validators.splittedDateRequiredValidator = function (rule) {        
  var dayFieldId = rule.ValidationParameters.dayFieldId;    
  var monthFieldId = rule.ValidationParameters.monthFieldId;    
  var yearFieldId = rule.ValidationParameters.yearFieldId;    
  return function (value, context) {                
    var dayIdx = $get(dayFieldId).selectedIndex;        
    var monthIdx = $get(monthFieldId).selectedIndex;        
    var yearIdx = $get(yearFieldId).selectedIndex;        
    if (dayIdx === 0 || monthIdx === 0 || yearIdx === 0) return false;        
    else return isValidDate(parseInt($get(yearFieldId).value), monthIdx, dayIdx);     

  };
};

function isValidDate(y, m, d) {
var date = new Date(y, m – 1, d);
var convertedDate = “” + date.getFullYear() + (date.getMonth() + 1) + date.getDate();
var givenDate = “” + y + m + d;
return (givenDate == convertedDate);
}

Ok let’s put everything together!
Assuming that our model defines a property ”BirthDate” like this…

[DateRequired(ErrorMessage = "Invalid date. Please specify valid values!")]
[DataType(DataType.Date)]
[DisplayName("Birthdate")]
public DateTime BirthDate { get; set; }

… if we put the following code in our View…

<% Html.EnableClientValidation(); %>

…
<%= Html.EditorFor(m => m.BirthDate, “Date”) %><br />
<%= Html.ValidationMessageFor(m => m.BirthDate) %>

…the output would be, for example, the following…

HTH

using System.Management;

internal class ProcessConnection {

   public static ConnectionOptions ProcessConnectionOptions()

   {

     ConnectionOptions options = new ConnectionOptions();

     options.Impersonation = ImpersonationLevel.Impersonate;

     options.Authentication = AuthenticationLevel.Default;

     options.EnablePrivileges = true;

     return options;

   }

   public static ManagementScope ConnectionScope(string machineName, ConnectionOptions options, string path)

   {

     ManagementScope connectScope = new ManagementScope();

     connectScope.Path = new ManagementPath(@"\\" + machineName + path);

     connectScope.Options = options;

     connectScope.Connect();

     return connectScope;

   }

}

public class COMPortInfo

{

   public string Name { get; set; }

   public string Description { get; set; }

   public COMPortInfo() { }     

   public static List<COMPortInfo> GetCOMPortsInfo()

   {

     List<COMPortInfo> comPortInfoList = new List<COMPortInfo>();

     ConnectionOptions options = ProcessConnection.ProcessConnectionOptions();

     ManagementScope connectionScope = ProcessConnection.ConnectionScope(Environment.MachineName, options, @"\root\CIMV2");

     ObjectQuery objectQuery = new ObjectQuery("SELECT * FROM Win32_PnPEntity WHERE ConfigManagerErrorCode = 0");

     ManagementObjectSearcher comPortSearcher = new ManagementObjectSearcher(connectionScope, objectQuery);

     using (comPortSearcher)

     {

       string caption = null;

       foreach (ManagementObject obj in comPortSearcher.Get())

       {

         if (obj != null)

         {

           object captionObj = obj["Caption"];

           if (captionObj != null)

           {

              caption = captionObj.ToString();

              if (caption.Contains("(COM"))

              {

                COMPortInfo comPortInfo = new COMPortInfo();

                comPortInfo.Name = caption.Substring(caption.LastIndexOf("(COM")).Replace("(", string.Empty).Replace(")",

                                                     string.Empty);

                comPortInfo.Description = caption;

                comPortInfoList.Add(comPortInfo);

              }

           }

         }

       }

     } 

     return comPortInfoList;

   }
}

Finally you can easily get the com port list in this way…

foreach (COMPortInfo comPort in COMPortInfo.GetCOMPortsInfo())

{

  Console.WriteLine(string.Format("{0} – {1}", comPort.Name, comPort.Description));

}

Other solutions?

• A first alternative is SetupAPI. You can find a complete example here.
• Secondly, you can try to use DevCon (a Microsoft tool that allows "device management" from the command line): you could use the

  System.Diagnostics.Process class to parse the standard output of the command line “>devcon find =ports”.

[TestMethod]
public void BitConverterVsStringConcatAndExtensionMethod()
{
  byte[] bytes = new byte[] { 0×00,0xAA,0xB0,0xC8,0×99,0×11,0×01,0×02 … };
  string expectedResult = "00AAB0C899110102…";
 
  string result1 = BitConverter.ToString(bytes).Replace("-",string.Empty);
 
  string result2 = string.Concat(bytes.Select(b => b.ToString("X2")));

  Assert.AreEqual(expectedResult, result1);
  Assert.AreEqual(expectedResult, result2);
}

OK no performance issue has been discussed. Aren’t you satisfied? Follow this thread !!! (4 years of discussion )

public class CustomersController : AsyncController

By default, ASP.NET MVC won’t call the ListCompleted method until the AsyncManager associated with the request says that there is no outstanding asynchronous operations. But it’s possible that one or more asynchronous operations might never complete!!! Moreover, if the callback for one of your asynchronous operations throws an exception before it calls the AsyncManager.OutstandingOperations.Decrement() method, the request will keep waiting a decrement until it times out! So, putting the AsyncManager.OutstandingOperations.Decrement() call inside a finally block would be fine .
The AsyncManager object has a built-in default timeout set to 45 seconds, so if the count of outstanding operations doesn’t reach zero after this long, the framework will throw a System.TimeOutException to abort the request. If you want to set a different timeout you can use the AsyncTimeout filter for specifying a different duration. If you want to allow asynchronous operations to run for an unlimited period, then use the NoAsyncTimeout filter instead.

Finally, we have to say that most applications will have an ASP.NET global exception handler that will deal with timeout exceptions in the same way as other unhandled exceptions. But if you want to treat timeouts in a custom way, providing a different feedback to the user, you can create your own exception filter or you can override the controller’s OnException() method (e.g. to redirect users to a special “Try again later” page).

Web Development Helper is a free browser extension for Internet Explorer that provides a set of tools and utilities for the Web developer, esp. Ajax and ASP.NET developers. The tool provides features such as a DOM inspector, an HTTP tracing tool, and script diagnostics and immediate window. Web Development Helper works against IE6+, and requires the .NET Framework 2.0 or greater to be installed on the machine.

Very cool

If you are migrating your database across different platforms or applications, then you know that it can not be done by simple copy-and-paste operations. To forget about difficulties associated with database conversion, you should try ESF Database Convert. This wizard-based tool addresses almost any database conversion need. Advanced converting mechanisms of the tool provide smooth conversion directly from/to any of the following database formats: Oracle, MySQL, SQL Server, PostgreSQL, Visual Foxpro, FireBird, InterBase, Access, Excel, Paradox, Lotus, dBase, Text and others(e.g.: Access to Oracle, Oracle to SQL Server, SQL Server to MySQL, MySQL to PostgreSQL…). Also you can convert any format of a database with ODBC DSN.
ESF Database Convert includes the support of table CLOB/BLOB, Primary/Foreign Keys, Indexes, Auto-ID and maps table and field names/types in converting. It provides all the required conversion options, taking into account the peculiarities of both input and output database formats. You can convert data exactly the way you want it.
The tool comes with the batch conversion mode that can enhance productivity by speeding up the entire conversion process. Our users regularly convert multi-million records databases using our software.

Here a preview

Moreover, O’Reilly has produced a poster called History of Programming Languages  which plots over 50 programming languages on a multi-layered, color-coded timeline.

The .NET Framework 3.5 Enhancements Training Kit includes presentations, hands-on labs, and demos. This content is designed to help you learn how to utilize the .NET 3.5 Enhancement features including: ASP.NET MVC, ASP.NET Dynamic Data, ASP.NET AJAX History, ASP.NET Silverlight controls, ADO.NET Data Services and ADO.NET Entity Framework.

What can I say… Happy download

• ImageButton
• DragDropManager
• GlassWindow
• BalloonDecorator
• ItemSkimmingPanel + SkimmingContextAdorner
• PennerDoubleAnimation
• ElementFlow ( Very  powerful ): allows you to display your items in different carousel like modes

P.S.: If you already have the Enterprise Library 3.0 installed, you must uninstall it before installing the Enterprise Library 3.1.

• LINQBridge is designed to work with the C# 3.0 compiler, as used by Visual Studio 2008.
• LINQBridge comprises a “LINQ to Objects” API for running local queries. (It doesn’t include an implementation of LINQ to SQL, nor LINQ to XML).
• LINQBridge also includes Framework 3.5′s generic Func and Action delegates, as well as ExtensionAttribute, allowing you to use C# 3.0′s extension methods in Framework 2.0. In fact
• LINQBridge lets you use nearly all of the features in C# 3.0 with Framework 2.0—including extension methods, lambda functions and query comprehensions. The only feature it does not support is compiling lambdas to expression trees (i.e., Expression<TDelegate>).

• .NET Base Class Libraries (including System, System.CodeDom, System.Collections, System.ComponentModel, System.Diagnostics, System.Drawing, System.Globalization, System.IO, System.Net, System.Reflection, System.Runtime, System.Security, System.Text, System.Threading, etc).
• ASP.NET (System.Web, System.Web.Extensions)
• Windows Forms (System.Windows.Forms)
• Windows Presentation Foundation (System.Windows)
• ADO.NET and XML (System.Data and System.Xml)

Moreover, in this great post, Shawn Burke shows us how to configure Visual Studio 2008 to Debug .NET Framework Source Code…. VERY INTERESTING!