So after looking at the “Dynamic Duo” in detail it appears there’s something missing. To further utilize the dynamic support it would be great to have a generic version of DynamicObject that would take an Interface as a type parameter so you could define sort of an contract for a subset of an object’s data (actually behavior) besides additional dynamic data. Something like:

public class MyDynamicObject : DynamicObject<IMyContract>
{
}

var name = new MyDynamicObject().Name;

And have Intellisense provide Feedback and show (at least some) of the typos. Really looking forward to that.

Dynamic Duo Part 1

The ExpandoObject I was talking about in my last post is actually not too much of a help in most cases meaning I didn’t miss it too much before it was there. There are some special scenarios but that’s about it. A much more interesting beast is DynamicObject. While the ExpandoObject is holding a internal collection of Properties and their values, DynamicObject is providing overrideable methods for member access like getting or setting members, calling methods and more. All calls on this object are channeled into a few methods. Every access to a Property like var name= myDynamicPerson.FirstName; will actually result in a call to the Method bool TryGetMember(GetMemberBinder binder, out object result). From there you can do with it whatever you want. Within the binder parameter is the Property Name, which gives you the member name asked for in the first place. For the above example its value would be “FirstName”. You can then access the Property value via Reflection or Expressions. This is a perfect place to put some code around it, decorating the actual call. The following code shows a simple override for Property getters:

var _Person = new DynamicPerson{ FirstName = "Paulie" };

public override bool TryGetMember(GetMemberBinder binder, out object result)
{
   result = _Person.GetProperty(binder.Name).GetValue(_Person, null);

   return true;
}

Using binder.Name the value for the requested Property is retrieved and put into the out variable result. The boolean return value indicates wether the call was successful meaning returning false will result into an Exception stating the requested member could not be found on the target object.

Using this approach it gets easy to actually implement single responsibilities like tracing, logging or security into different classes and chain these. Tracing could be done like this for example:

public class DynamicTracer : DynamicObject
{
    private readonly DynamicObject decoratedObject;
    private ITracer _Tracer = new FakeTracer(); 

    public DynamicTracer(DynamicObject decoratedObject)
    {
        this.decoratedObject = decoratedObject;
    }

    public override bool TryGetMember(GetMemberBinder binder, out object result)
    {
        _Tracer.Trace(string.Format("-> Before member access ({0})", binder.Name));
        decoratedObject.TryGetMember(binder, out result);
        _Tracer.Trace(string.Format("-> After member access ({0})", binder.Name));

        return true;
    }
}

It’s just wrapped around the original DynamicObject calling its TryGetMember method with the given Parameters. All that’s needed is the target object (dynamic) which is injected via the constructor and the actual call gets decorated with the tracing calls.

This can be repeated to achieve a real chain of functionality (Handler chain). A simple (and pretty useless) security managing class could look like this:

public class DynamicSecurityManager : DynamicObject
{
    private readonly DynamicObject decoratedObject;

    public DynamicSecurityManager(DynamicObject decoratedObject)
    {
        this.decoratedObject = decoratedObject;
    }

    public override bool TryGetMember(GetMemberBinder binder, out object result)
    {
        result = null;
        if(binder.Name != "SecureInfo")
        {
            decoratedObject.TryGetMember(binder, out result);
            return true;
        }

        System.Console.WriteLine("-> The requested info is not for your eyes!!!");
        return true;
    }
}

You would then instantiate and use it like this:

dynamic person = new DynamicSecurityManager( 
                    new DynamicTracer( 
                        new DynamicPerson( 
                            new Person { FirstName = "Paulie" })));

var name = person.FirstName;

What this gives you is the actual object (DynamicPerson) surrounded by a Tracing component surrounded by a security component.

So when should you use this?! Well you shouldn’t forget that all calls will be based on Reflection, going this route. This doesn’t have to be a problem, just be aware of the implications. This means performance will degrade when doing more calls via this technique. This can be adressed with caching the compiled invocation delegates or even better the usage of HyperPropertyDescriptors. To be honest there are better solutions around for most situations, but not all. There is the Castle DynamicProxy as long as all target members are virtual and there’s PostSharp for Aspect Oriented Programming using a post compiler so the resulting code will be executed like it was written that way. Direct invocations, no reflection, no Voodoo…

Still, if you don’t want to introduce third party libs or don’t want to pay for PostSharp (there’s a free community editon available) DynamicObject might be something to try.

Get the sample code from http://dl.dropbox.com/u/13456770/IDevign/IDevign.Dynamic.zip.

dynamic expando = new ExpandoObject()
expando.MyProperty1 = "This is a string prop";
expando.MyProperty2 = 12;
expando.MyFunction = (Func<String>)(() =>
                     {
                         return String.Format("{0}", expando.MyProperty1);
                     });

Furthermore it supports change notifications via INotifyPropertyChanged out of the box as well as Events (sort of).

So do you need this? As always: it depends. On what? Well if you are looking for a dynamic structure you could also use a combination of Dictionary-Voodoo like this:

Dictionary<String, object> paulie = new Dictionary<string, object>();
paulie["FirstName"] = "Paulie";
paulie["LastName"] = "Baker";

Dictionary<String, object> people = new Dictionary<string, object>();
people["Paulie"] = paulie;

Console.WriteLine(((Dictionary<string, object>)people["Paulie"])["FirstName"]);

Besides the much cleaner coding, there’s again INotifyPropertyChanged, Methods and Events on the Expando side. Also it implements IDynamicMetaObjectProvider which allows for interop with DLR objects.

As always the source can be downloaded here: http://dl.dropbox.com/u/13456770/IDevign/IDevign.Expando.zip

C# 4 introduced the new dynamic keyword for scenarios in which a more dynamic approach is helpful. This includes working with COM-Interop Types, the dynamic DLR languages like IronPython and IronRuby or working with the HTML Document Object Model (DOM). I usually like to use it when I am testing out different things with existing code where it is a shortcut to using reflection.

Show me an example already, will ya?!

((dynamic)myObject).Do("What has to be done");

What’s interesting about this is that the compiler will not check whether the Method Do exists on the myObject‘s class. It just assumes you know what you’re doing (yeah, right…) and will evaluate the call at runtime. And of course that means you will get a runtime exception instead of a compile-time exception which is usually considered a bad thing. Besides that dynamic execution is always noticeable slower than direct invocation so this is only for the cases where it does not work otherwise, is absolutely performance uncritical (as if you could say before, sure…) or you’re using Reflection anyways.

Summing up: You can turn off compiler checking on dynamic calls but be aware you are losing benefits of the static checking compile time safety and invocation speed! If that’s acceptable: go on!

As a side note: ReSharper will list member usages divided into direct and dynamic invocations, although as always that’s a setting and you can tweak it any way you like.

You can download the linked solution to see a few simple variations of dynamic usage including dynamic parameters which allows you to pass in any object as the signature of the called method will not be evaluated anymore.

And remember: “With great power comes great responsibility!”

http://noteandpoint.com/

First things first: You will need to install the EF 4.0 CTP 4. You can download it from here.

1. Setting the demo context

We will be modeling a simple scenario from the real estate sector using properties, their adresses and agents who are selling the properties. Pretty simple, huh?!

2. The sample code

Open the Sample Solution (download is located at the end of the post) called IDevign.EF4. In there are two projects. The first one is called IDevign.EF4.Core and holds everything related to the Entity Framework like configuration, mapping and all loading/saving procedures. The second project is called IDevign.EF4.Domain. In here you will find the domain model which will then be persisted to the database. The following Class Diagram shows the entities we’re going to create:

IDevign.Domain Class Diagramm

As I said before this model is pretty trivial so we can concentrate on the real topic: the EF 4.0. Now focus on the entites. These are all simple classes containing only a few properties. Just to clarify: as these classes are entities you are encouraged to put some domain logic (methods / behaviour) into them, although this sample has no need for that.

3. Creating the Domain Model

The first class we are looking at is RealEstateProperty (Property is not technical in this case):

public class RealEstateProperty
{
   public int Id { get; set; }
   public Agent ContractedBy { get; set; }
   public Address PropertyAddress { get; set; }
   public ICollection
 Buyers { get; set; }
}

Note that the Id Property will be taken as the Primary Key for this entity when using the Feature CTP 4 (see my previous post on EF 4 Conventions here). You don’t have to specify this explicitly like with the plain EF 4. The other point of interest is the ICollection of PotentialBuyer which stores people who are interested in buying this property. This results into an Foreign Key Relation from PotentialBuyer to RealEstateProperty which stores this information on each PotentialBuyer’s property interest. Also the addresses are entities by themselves. Again, this is not a full-scale domain model design regarding adresses as entities and not complex types (sql server feature), etc.

public class Address
{
   public int Id { get; set; }
   public string Street { get; set; }
   public string StreetNo { get; set; }
   public string City { get; set; }
   public string Zip { get; set; }
}

Nothing special in here. But to spice things up a little I created a little inheritance part inside this demo. There are two kinds of persons: Agents and PotentialBuyers. Agents show and sell properties to PotentialBuyers. Both types inherit from Person. All Persons have a name therefore the fullname goes into the base class. The specific parts are in the two specialized classes. But how does this whole thing work?

3.1 Inheritance Strategies:

There are three different strategies how inheritance can be handled inside of an relational database. Without going into details on these strategies here is a little wrap-up:

• Table Per Type (TPT) – This means there will be one table in the database for every type you map. In our case this would be three tables. One for PotentialBuyer, one for Agent and one for the base type Person.
• Table Per Hierarchy (TPH) – This is what we are doing here. There will be one table for all sorts of persons named People. It contains the data for Agents and PotentialBuyers. To differentiate between the two types an additional column is needed. This is a Discriminator column specifying the concrete type for each row. I will show you later how class hierarchies can be mapped using a discriminator.
• Table Per Concrete type (TPC) – The last strategy is using one table per concrete type. So in our case this would be two tables for Agent and PotentialBuyer. Each table will also hold the columns of the base type person. Using the first strategy (TPT) all base type data gets into its own table.

Having explained the possibilities of mapping class hierarchies to a relational database, we will go with the second strategy “Table Per Hierarchy” which is the most intuitive one. So here is the code for the three entity classes:

public abstract class Person
{
   public int Id { get; set; }
   public string FullName { get; set; }
}

public class Agent : Person
{
   public ICollection Properties { get; set; }
}

public class PotentialBuyer : Person
{
   public double MaxPrice { get; set; }
}

As shown in the above code Agents can have multiple objects (properties) for selling, while PotentialBuyers usually have some MaxPrice they are willing to pay. This is the simple Domain Model we will be using to create, save and load some data utilizing the EF 4.

4. DbContext and DbSet<TEntity>

When working with the standard EntityFramework there are two classes that are really important and often used: ObjectContext and ObjectSet. The new Feature CTP introduces two new simplified abstractions of these classes: DbContext and DbSet<TEntity>. There are several reasons why the new classes were introduced, one of them being full backward compatibility. So it is up to you wether you use the classic versions (Entity Designer Support e.g.) or the new ones which are essentially made for the Code-First flavor.

I created a class RealEstatePropertyCatalog which inherits from DbContext and called it (RealEstateProperty)Catalog, because it does not only allow to load or save entities, but it also gives access to DbSets of all entity types like DbSet<Agent> for example:

public class RealEstatePropertyCatalog : DbContext
{
    public RealEstatePropertyCatalog(DbModel model)
        : base(model)
    { /* nothing here */}

    public DbSet Properties { get; set; }
    public DbSet
 People { get; set; }
    public DbSet Agents { get; set; }
    public DbSet
 Buyers { get; set; }
    public DbSet
<address> Adresses { get; set; }

    ///
    /// Here you can customize Schema related things.
    ///
    ///
<span> </span>The model builder.
    protected override void OnModelCreating(System.Data.Entity.ModelConfiguration.ModelBuilder modelBuilder)
    {
        base.OnModelCreating(modelBuilder);

        modelBuilder.Entity
()
            .MapHierarchy()
            .Case
(person => new { person.Id, person.FullName, Discriminator = 0 })
            .Case(agent => new { agent.Properties, Discriminator = 1 })
            .Case
(potentialBuyer => new { potentialBuyer.MaxPrice, Discriminator = 2 })
            .ToTable("dbo.Contacts");
    }
}

Besides the DbSet Properties the override of the OnModelCreating method is important. Here you can customize different aspects of the model creation. The above code is mainly using this feature for mapping class hierarchies to a single table using a descriminator. You can see the the call to MapHierarchy() for the Person entity and then following a Case construct to define the mappings for each type of the hierarchy. Note the Discriminator information to differentiate between them. Also the ToTable() Method defines the name of the table within SqlServer. Inside OnModelCreating you can fully customize the way the model is being built, but we’re not going to dig here much deeper for now.

5. Mapping (Configuration)

The next class we are looking at is RealEstatePropertyConfiguration. This is a mapping class and contains all information about what properties of an entity should be written into which column of the table. In the first release of the Entity Framework this sort of “external” mapping was not available so many people denied using it. NHibernate for example is offering this feature for years. Using the standard EF 4.0 you would have to define the Ids (Primary Keys) of all your entities here and everything else like relations. The Feature CTP and its Conventions takes care of all that for you. Actually you don’t need the class below, but I threw it in for reference purposes so that you can see how you’d normally map a class to the Database. Pretty nifty timesafer! 

public class RealEstatePropertyConfiguration : EntityConfiguration
{
    public RealEstatePropertyConfiguration()
    {
        HasRequired(property => property.ContractedBy).WithMany(a => a.Properties);
    }
}

6. EF Configuration

Now we will take a look at configuring our Code-First solution. The configuration code can be found inside the Bootstrapper class. This code could also be inside the main method but I just decided to move it into a new class to separate the configuration code a little from the rest. The whole configuration code is placed inside the Run Method:

internal class Bootstrapper
{
    public DbModel Run()
    {
        // Takes the connection string from the app.config
        Database.DefaultConnectionFactory =
                      new SqlConnectionFactory("RealEstatePropertyCatalogConnectionString");

        #region Database Initialization

        // Changes in the DomainModel cannot be applied (yet) without
        // dropping the old database. Therefore changes result in an
        // Exception unless you force a db drop and recreate it.

        // additional strategies: (names are self-explanatory)
        // Database.SetInitializer(
                // new AlwaysRecreateDatabase());
        // Database.SetInitializer(
                // new CreateDatabaseOnlyIfNotExists());
        // Database.SetInitializer(
                // new RecreateDatabaseIfModelChanges());

        // switch off Generation if you have an existing Database
        //Database.SetInitializer(null);
        Database.SetInitializer(new RealEstatePropertyInitializer());

        #endregion

        var builder = new ModelBuilder();
        builder.Configurations.Add(new RealEstatePropertyConfiguration());
        builder.Entity
();
        builder.Entity
<address>();
        builder.Entity();

        return builder.CreateModel();
    }
}

Line 6 sets the DefaultConnectionFactory. There are predefined Factories like the SqlConnectionFactory (Sql Server) which can take a ConnectionString name. The ConnectionString is defined inside the app.config so choosing different EF configurations depending on your enviroment (Production, Development, Testing) can be easily achieved. Lines 20 to 26 are showing the available strategies for seting up your database when running the Bootstrapper, which is usually when starting the solution. Line 26 even shows a custom implementation (RealEstatePropertyInitializer), but let’s look at the standard strategies first, although the names are pretty self-explanatory:

• AlwaysRecreateDatabase - This strategy always drops the whole database and recreates it. This is helpfull for full integration testing when an untouched db is what you need before every test.
• CreateDatabaseOnlyIfNotExists - If no database is found it will be created by the Entity Framework.
• RecreateDatabaseIfModelChanges - This only recreates your database if the underlying model (also the mapped entities) were changed.
• Custom - You can implement your own strategies which is what I did in the demo app.
• null - If you don’t need any initialization (read only or pre-existent database f.e.) you can just turn it off.

Again a static method (SetInitializer) on the Database class can be used to set the initializer like we did before, when setting the DefaultConnectionFactory. It takes an instance of a recreation strategy. If you want to turn this feature off just put in null as parameter. I already said that you can implement your own custom strategy, but how does it work exactly?!

public class RealEstatePropertyInitializer : AlwaysRecreateDatabase
{
    protected override void Seed(RealEstatePropertyCatalog context)
    {
        var agent1 = new Agent {FullName = "Paula Waters"};

        var prop1 = new RealEstateProperty {ContractedBy = agent1};
        var prop2 = new RealEstateProperty {ContractedBy = agent1};
        var prop3 = new RealEstateProperty {ContractedBy = agent1};

        agent1.Properties = new List {prop1, prop2, prop3};

        context.Agents.Add(agent1);
    }
}

This is a simple custom Initializer which inherits from the AlwaysRecreateDatabase strategy and afterwards put some init data into the database using the context.Agents.Add call.

Back to the last lines of the Run Method: Here we are just adding our configuration to the ModelBuilder, then we add all types we need in our model and finally call CreateModel which is the last thing to do before starting to utilize the Entity Framework. Now everything following is how to write /read data from the database using EF.

7. Putting some data in and querying it

Inside the Program.cs file you can find the Main method which contains all the data access code within an using statement for the RealEstatePropertyCatalog. Using such a Context/Catalog object is easily underestimated. There is a brilliant blog entry by Ayende Rahien on this topic for NHibernate which can be translated to EF. Just replace the word ISession with DbContext/ObjectContext in your Head: http://msdn.microsoft.com/en-us/magazine/ee819139.aspx. Having said that let’s look at the last section. Inside the Main method we are creating an object graph, then add it to the context and call SaveChanges on it. Afterwards we can execute queries using LINQ against the DbSets within our Catalog.

8. Summing it up

That’s about it. I hope I managed to show you the ease of using the new EF, while still achieving persistance ignorance through using the Code-First model. I was pretty impressed when I first used the new Feature CTP and although it is not perfect yet, I believe it’s heading into the right direction. Let me know if this demo helped you and what you are thinking of the Feature CTP.

Best regards

Gope

SOURCE CODE: DOWNLOAD

So what are conventions and how can we use them? Well, the good news is: conventions just work. You don’t have to do anything special to use them, but only follow a few rules in the naming of your entities and their properties. For example: books usually have an ISBN number as an identifier. You will have to tell EF that the property ISBN is the PrimaryKey for the entity Book. But if your entity was a customer who doesn’t have a natural id you could use a property like Id or CustomerId. Now, usually you still would need to tell EF that this is your PK. This is where conventions come into the game. Using its conventions, EF keeps looking for Properties in an entity with a specific naming style. If it finds one that is either named Id or is a combination of the entity name and the word Id like CustomerId it expects this to be the Identifier (PrimaryKey) for this entity. So, this can be pretty timesaving! Following you can see which new conventions can be found inside of the new Feature CTP 4:

Primary Keys:
Just name the identifier property of your entity class Id or “entity + Id” (CustomerId f.e.) and it will be considered the primary key field. This is not case sensitive.

Relationships:
This is a cool one: if you have two entities related to each other like in the following sample, these can be wired up pretty easy:

 public class EntityOne
{
    public int Id { get; set; }
    public ICollection<EntityTwo> OtherEntities { get; set; }
}

public class EntityTwo
{
    public int Id { get; set; }
    public EntityOne Parent { get; set; }
}

 One point though, this only works if there is only one navigation property on either of the two types.

Type Discovery:
This is about referenced types. Using the regular release of EF 4.0 referenced types would not be taken into account if not specified via a derived context or using the fluent API. This is not as unsual, as it might sound at first. Remeber WCF contracts referencing custom types? There also is a special attribute (KnownTypeAttribute) to tell the DataContractSerializer that some types need to be included. Anyways, just use it and it will work now. No strange TypeNotFound Exceptions.

Complex Types:
The last one for now is about complex types which represent custom types in Sql Server. You don’t have to register it explicitly, but EF will understand that a referenced type will be a complex type if no primary is defined or can be infered from the property names (see Primary Keys convention).

Although you don’t have to do anything to take advantage of this conventions I do beliefe it’s good to understand what conventions are in place and why EF 4.0 is behaving the way it does.

The next post on the EF 4.0 will be a full demo app. Until then, happy coding!

Prerequisites:

To make life a little easier I am using the PRISM Framework (aka CAG – Composite Application Guidance for WPF and Silverlight -> http://msdn.microsoft.com/en-us/library/ff648611.aspx) and its contained DelegateCommand. This allows you to directly define a Command as a delegate within your code. You do not have to create a new class for that, but rather you can define it directly within your ViewModel Class. You can also use the MVVM Foundation RelayCommand (http://mvvmfoundation.codeplex.com/). It offers similar capabilities. For the demo code I extracted the two required classes from the PRISM Framework so you do not need it for compiling. 

I am not gonna explain the MVVM stuff anymore. There are lots of ressources on the net you can find on that topic. 

Step 1: Define the ICommand to bind to within your ViewModel – You got one, right?!

public DelegateCommand _EnterCommand;
public DelegateCommand EnterCommand
{
   get
   {
      return _EnterCommand ??
             (_EnterCommand = new DelegateCommand(o =>;
                                  {
                                     LabelContent = "You pressed enter!";
                                  },
                                  o =>; true));
     }
  }

That’s how you define the command. It’s just a simple property of type ICommand. At first access we check for null and if it is not yet initialized, we create a new DelegateCommand which changes another Property within our ViewModel. That change will be reflected within the UI via DataBinding. So, what’s next?

Step 2 (Markup): Use a KeyBinding

The most simple way to achieve this is to use a KeyBinding like this:

<TextBox> 
   <TextBox.InputBindings> 
      <KeyBinding Command="{Binding EnterCommand}" Key="Enter"/> 
   </TextBox.InputBindings> 
</TextBox>

This will work out of the box but there’s also the possibility to create a Behavior. Behaviors were introduced by the Expression Blend Team but be used also without Blend. They encapsulate a given behavior which can be dropped on Controls and parameterized within the UI. If you need to achieve something like the above it might be even faster to just create a Behavior and drop it on all Controls that need it. Therefore:
 

Step 2 (Behavior): Create the actual EventHandling:

First we need to create a class dedicated for the handling of the event: 

public class TextBoxEnterBehavior : CommandBehaviorBase<TextBox>
{
    /// <summary>
    /// Initializes a new instance of the <see cref="TextBoxEnterBehavior"/> class.
    /// </summary>
    /// <param name="element">The element.</param>
    public TextBoxEnterBehavior(TextBox element) : base(element)
    {
       element.KeyUp +=(sender, args) => {
                                             if (args.Key == Key.Enter)
                                             {
                                                 base.ExecuteCommand();
                                             }
                                         };
    }
}

This is pretty straightforward. We only handle the wanted event inside the Constructor and trigger the execution of the command. The concrete command will be wired up later via DataBinding in XAML. Of course one could reach the args.Key to the DelegateCommand in the ViewModel for further processing but this depends on the requirements. If you are looking for a specific key stroke this behavior holds it all together. There’s no mixup of why/when the command gets triggered and what it’s supposed to do when being fired. 

Step 3: Create the Attached Properties for DataBinding

 We do need another class for that and I called it “Attached” which gives us a nice syntax when used like: ns:Attached.Command=”{ Binding MyCommand }”. The class looks like this (with all comments stripped off): 

public static class Attached
{
    private static readonly DependencyProperty CommandProperty = DependencyProperty.RegisterAttached("Command", typeof(ICommand), typeof(Attached), new PropertyMetadata(OnSetCommandCallback));
    private static readonly DependencyProperty TextBoxEnterCommandBehaviorProperty = DependencyProperty.RegisterAttached("TextBoxEnterCommandBehavior", typeof(TextBoxEnterBehavior), typeof(Attached), null); 

    public static ICommand GetCommand(DependencyObject obj)
    {
        return (ICommand) obj.GetValue(CommandProperty);
    } 

    public static void SetCommand(DependencyObject obj, ICommand value)
    {
        obj.SetValue(CommandProperty, value);
    } 

    private static void OnSetCommandCallback(DependencyObject dependencyObject, DependencyPropertyChangedEventArgs e)
    {
        TextBox element = dependencyObject as TextBox;
        if(element != null)
        {
            TextBoxEnterBehavior behavior = GetOrCreateBehavior(element);
            behavior.Command = e.NewValue as ICommand;
        }
    } 

    private static TextBoxEnterBehavior GetOrCreateBehavior(TextBox element)
    {
        TextBoxEnterBehavior behavior = element.GetValue(TextBoxEnterCommandBehaviorProperty) as TextBoxEnterBehavior;
        if(behavior == null)
        {
            behavior = new TextBoxEnterBehavior(element);
            element.SetValue(TextBoxEnterCommandBehaviorProperty, behavior);
        } 

        return behavior;
    } 

    public static TextBoxEnterBehavior GetTextBoxEnterCommandBehavior(DependencyObject obj)
    {
        return (TextBoxEnterBehavior)obj.GetValue(TextBoxEnterCommandBehaviorProperty);
    } 

    public static void SetTextBoxEnterCommandBehaviour(DependencyObject obj, TextBoxEnterBehavior value)
    {
        obj.SetValue(TextBoxEnterCommandBehaviorProperty, value);
    } 

}

On top there are the two DependencyProperties for the DataBinding. CommandProperty is specifying a Callback for the Set Method (OnSetCommandCallback) which is doing the heavy lifting. It connects the TextBoxEnterBehavior, the Command and the TextBox.

Step 4:  Binding to the DelegateCommand in XAML 

Now all that’s left to do is the binding within the view. It looks as simple as this: 

<TextBox Name="MyText" Behaviors:Attached.Command="{ Binding EnterCommand }" Margin=...
 

You can download the source code below. 

Enjoy! 

Source Code zip

The Lint Editor Helper

Although I don’t like “Best Practices” as a term I think it’s the best description for this Add-In. The guys from Typemock built an VS 2010 Add-In showing code smells for Unit Tests. And NO! This is not just for the Typemock Framework but for all others as well. A little indicator icon on the left editor side is showing possible problems within your test. When clicking on it a little window with contextual information and further help is opened.
So what is Type Lint checking for?! To answer this one should refer to the brilliant book “The Art of Unit Testing” by Roy Osherove who is also the guy behind the song: “Every Build You Break” (just imagine the melody of “Every Breath You Take”). Back to the topic: His book is a great introduction to Unit Testing and there are many hints inside of it. These were used as a basic ruleset for example don’t use conditionals (if / else) within your code or don’t call test methods from other test methods.

Currently people can help implement rules (yes, they also provide a Lint SDK), so this will get even better in the future.

Go download Test Lint, have fun, learn something new and increase your (test) code quality!