Advanced Domain Model queries using Linq - Part III

I didn't intend to post so quickly after my last post, but some comments from Nick motivated me to try something different.

So what's changed?

Not much.  Defining your query properties has changed (and obviously some implementation details).  All the linq syntax stuff stays the same.

Here's the same Loan class, rewritten:

class Loan
{
    [OverdueFee]
    public decimal OverdueFee
    {
        get { return OverdueFeeAttribute.Property.GetValue(this); }
    }
 
    [IsOverdue]
    public bool IsOverdue
    {
        get { return IsOverdueAttribute.Property.GetValue(this); }
    }
 
    [DaysOverdue]
    public double DaysOverdue
    {
        get { return DaysOverdueAttribute.Property.GetValue(this); }
    }
}

And here's our query property definition:

class IsOverdueAttribute : QueryPropertyAttribute
{
    public IsOverdueAttribute() : base(Property) { }
 
    public static readonly QueryProperty<Loan, bool> Property = new QueryProperty<Loan,bool>(
        x => (x.DateReturned == null && (DateTime.Now - x.DateBorrowed).TotalDays > x.LoanPeriod));
}
 
class OverdueFeeAttribute : QueryPropertyAttribute
{
    public OverdueFeeAttribute() : base(Property) { }
 
    public static readonly QueryProperty<Loan, decimal> Property = new QueryProperty<Loan, decimal>(
        x => (decimal)(x.DaysOverdue * 0.45));
}
 
class DaysOverdueAttribute : QueryPropertyAttribute
{
    public DaysOverdueAttribute() : base(Property) { }
 
    public static readonly QueryProperty<Loan, double> Property = new QueryProperty<Loan, double>(
        x => x.IsOverdue ? (DateTime.Now - x.DateBorrowed).TotalDays - x.LoanPeriod : 0);
}

What's the difference?

Well, depending on your programming tastes, it's cleaner.  We've reduced some of the tight coupling, and we now have the ability to spread the logic (which is more suitable in certain situations).

And if you're wondering why I seem to have an obsession with static members, it's mainly due to performance - and truth be told, I'm pre-optimizing here.  Generally I'm not such a fan... honest!

Performance anxiety

Speaking of performance, using Attributes has a penalty.  According to my tests, it's roughly 30% slower to parse the expression.  

This might sound like a lot, but we're talking about 0.37 vs 0.28 milliseconds per query here - and once you consider the database retrieval time... it's really nothing.

I don't even parse the expression tree with linq to objects - so no impact at all!

Bonus code (Expression Parser)

Here's my expression parsing code, I know you want to see it:

class QueryPropertyEvaluator : ExpressionVisitor
{
    protected override Expression VisitMemberAccess(MemberExpression m)
    {
        if (m.Expression != null)
        {
            var attribute = Attribute.GetCustomAttribute(m.Member, typeof(QueryPropertyAttribute)) as QueryPropertyAttribute;
 
            if (attribute != null)
                return Expression.Invoke(attribute.Property.GetExpression(), m.Expression);
        }
 
        return base.VisitMemberAccess(m);
    }
}

Beautiful isn't it!

Feedback please

If you've been following this little series, I'd love to hear what you think of the new syntax.

I'm still hesitant, since this new syntax results in more code - but I think it's a cleaner approach.


As usual, you can find the sample app here - enjoy!