[Test]
public void can_create_linq_query_from_arbitrary_criteria_query()
{
    var criteria = session.CreateCriteria<User>();
    criteria.Add(Restrictions.Le("RegisteredAt", new DateTime(2000, 1, 1)));

    var query = session.Linq<User>(criteria)
        .Where(u => u.Name == "nhibernate" || u.Name == "ayende");

    var list = query.ToList();
    Assert.AreEqual(1, list.Count);
    Assert.AreEqual("nhibernate", list.Single().Name);
}

My specific reason for adding this has to do with a custom ICriterion (more on that later) I needed to use in one of our criteria queries that I wanted to expose as an IQueryable.  This method of being able to build a linq query from an arbitrary criteria seemed to solve my problem rather elegantly.

Let me know if you think this is crazy or if you like.

As of now, it is available in the trunk r1099.

(from p in db.Patients
from r in p.PatientRecords
where r.Type.TypeCode == 7
select r).Sum(r => r.Amount);

yet, this query (which is equivalent) will blow up in your face:

db.Patients.SelectMany(p => p.PatientRecords)
    .Where(r => r.Type.TypeCode == 7).Sum(r => r.Amount);

The reason it fails is very implementation-specific.  Under the covers, the C# compiler will convert that first query into an expression looking something like this:

db.Patients.SelectMany(p => p.PatientRecords, (p, r) => new { p = p, r = r })
    .Where(pr => pr.r.Type.TypeCode == 7).Sum(pr => pr.r.Amount);

Our second query which uses the overload of SelectMany that doesn’t specify the result selector fails because NHibernate.Linq specifically requires that result selector in order to know which alias to use for that subcriteria for the rest of the query (yes, this is a really bad implementation and requires that you use the same lambda parameter names throughout your query).

Simple enough, let’s just drive around the pothole and explicitly state our parameter name by changing our second query to look like this:

db.Patients.SelectMany(p => p.PatientRecords, (p, r) => r)
    .Where(r => r.Type.TypeCode == 7).Sum(r => r.Amount);

Ahh,explosions still abound.  That query will generate an error similar to: “Type is not an association” or “Could not resolve property: Type”.

It turns out,that NHibernate.Linq’s SelectMany support depends on that anonymous type leading the entity types in the query (pr.r in the compiled first query).  Without this leading anonymous type, the parser does not assign a subcriteria to that many-to-one traversal through r.Type.  That is highly upsetting because the query that we are writing is actually more like this:

db.Patients.SelectMany(p => p.PatientRecords, (p, r) => r)
    .Where(specification.IsSatisfied()).Sum(r => r.Amount);

where specification.IsSatisfied() returns a dynamically generated Expression<Func<PatientRecord, bool>>.  I can’t rewrite those specifications to use some query-specific anonymous type and I shouldn’t have to.

On a mission, I fired up the NHibernate.Linq source code and hacked away at it until this specific scenario was supported.  There is still the limitation that you must use the second overload of SelectMany that accepts the result selector.  There is no way of easily getting around that with the current implementation based off of the Criteria API.  However, despite all of NHibernate.Linq’s shortcomings, my specifications now work just fine (running some pretty complex queries).

If you are having similar frustrations, go grab the latest trunk r1010.

…until the next bug

P.S. I am very much looking forward to NH.Linq 2.0 using relinq and the new AST parser.

Here are some informal release notes:

The implementation uses the NHibernate Criteria API under the covers, so anything it doesn’t support, NH.Linq won’t support.  Other things were just too hard to implement using the Criteria API.  Some major things this includes are group joins, subqueries in select clauses, and groupby.

However, despite that, limited subqueries are supported in the where clause.  Namely, using Count, Sum, Max, Min,Avg,and Any methods.  You can also use SelectMany queries (rather than GroupJoin) to do queries like this:

from o in db.Orders
from ol in o.LineItems
where ol.Price > 10
select o;

or this:

from o in db.Orders
where o.LineItems.Any(ol => ol.Price > 10)
select o;

All in all, it is a tried and tested implementation.  It has been used on number of projects in production for two years now.  As long as you know where the pitfalls are and how to avoid them, it is a useful addition to your NH toolkit.

Now, if you are saying to yourself, “well, that sucks, I really wanted to use GroupJoin and I want to nest other queries in my select clause.”  Fear not, this is where Steve Strong and the re-linq guys come in to save the day.  Steve has done a lot of all of the work on porting over the current HQL parser that is active in NHibernate 2.1.  The new linq implementation will interact with it natively (rather than use the Criteria API as an intermediary).  The current implementation has pretty much reached its upper limit on what it can do – limited by what the Criteria API can do.  The new implementation has much more grandiose plans than the current release.  It is the future, but, as most of us live in the present, this release is now.

For all intents and purposes, consider this a stopgap release.  Again, that doesn’t mean its not capable – just don’t expect major new features from this implementation.

Thanks to Tuna and Oren for pushing this release out the door.

An old software slogan at Living Videotext: "We Make Shitty Software... With Bugs!" It makes me laugh! We never ran this slogan in an ad. People wouldn''t understand. But it''s the truth. We make shitty software. And so do you!

Software is a process, it''s never finished, it''s always evolving. That''s its nature. We know our software sucks. But it''s shipping! Next time we''ll do better, but even then it will be shitty. The only software that''s perfect is one you''re dreaming about. Real software crashes, loses data, is hard to learn and hard to use. But it''s a process. We''ll make it less shitty. Just watch!

Talking with an unhappy customer, first validate their belief that you''ve let them down. I agree that our software isn''t perfect. You won''t get an argument here. Let''s move on, find a workaround, a way to get your data back. And we promise to take a look at this problem and, if possible, fix it in the next release.

And that is back from 1995.  Wow, I was only 10 years old back then…

To give you a concrete example of what I am talking about, check back to Ayende’s EncryptedStringUserType.  Rather than getting an instance of ICryptoProvider via a singleton accessor, it is now possible to have NHibernate inject the ICryptoProvider dependency through the constructor.  This is very valuable in cases where the ICryptoProvider has other dependencies or has some parameters that need to come from configuration.  You get full support from the container for that.

Fabio wrote up a post describing the implementations for Castle and Spring.  So, I thought I’d follow suit with an implementation for my new favorite container, Autofac (why it is my new favorite container will be a topic for another post).

To use it, make sure you are using the latest trunk of NHibernate.  Then, just add a reference in your project to Autofac.Integration.NHibernate.  At this time, the only way to configure the BytecodeProvider is programmatically.  So, BEFORE you call new NHibernate.Cfg.Configuration().Configure(), you need to set the BytecodeProvider to the AutofacBytecodeProvider.

containerProvider = new ContainerProvider(builder.Build());

Environment.BytecodeProvider = new AutofacBytecodeProvider(
    containerProvider.ApplicationContainer, new ProxyFactoryFactory());

Then just enjoy the DI goodness integrated with NH.  If any type NHibernate needs is not registered with the container,it will fall back to creating the type with Activator.CreateInstance.

The code can be found here.  I am going to contact the Autofac guys and see about putting this into the Autofac.Contrib project.

Update: This is now included in the Autofac.Contrib project – check it out here.

One particular quote that stood out in my mind when getting to know BDD was this:

Language you use shapes how you think... and if you want to change how you think it can help to first change your language.

It is true in that just changing seemingly insignificant things like the language and syntax of your tests can affect how you think about your tests and ultimately how and what tests you end up writing.

I set out to find a solution to help me start writing BDD-style tests (ehh, I mean specs) in an existing project which already used xUnit.net.  I really liked some of the things from SpecUnit, but I didn’t want to be tied to NUnit.  I also found the xUnit BDD Extensions project on Google Code – but I took issue with some of the syntax with that.  Also, it seemed to be trying to do too much.  I just wanted simple BDD style integration with xUnit without any excess baggage.

One of the things I really like about xUnit (and the reason why I use it over MBUnit and NUnit) is its simplicity.  It is clean, elegant, and efficient at what it does.  It provides exactly what you need and nothing more.  It also makes use of native C# semantics for its syntax.  For instance, rather than relying on a TestSetup or TestTearDown attribute for a setup method to a test, it relies on C# constructors and the IDisposable interface to handle such things.  When writing test cases with this syntax, it feels much more natural.

Anyway, I ended up finding this BDD solution for xUnit by Fredrik Kalseth.  This was almost exactly what I was looking for, except that I didn’t like having to override InitializeContext in my spec classes.  I wanted to include the context in the constructor of the class like normal xUnit test classes.

Also,some of my current test code relies on test base classes for some of its functionality – and I didn’t want to force my tests to inherit from a Specification class just to get BDD style testing done.

Last but not least,up until the latest 1.1 release of xUnit, the xunit.extensions assembly contained these nice .Net 3.5 extension methods for assertions in a very BDD style way.  It allowed you to write code like this:

customer.Email.ShouldEqual("test@example.com");

With the latest release, however, these extension methods were deemed unworthy and moved to the xUnit Samples project.  Boo I say to you.  I want, neigh, need these extension methods back.

Long story short, I ended up taking elements from all three of these solutions along with the extension methods from the samples project and created my own.  I present to you Chad’s version of xUnit BDD Extensions.

Some of the design goals of this project:

• Use natural C# constructs to control things such as BDD contexts and concerns.  For example, the context of the specification is defined in the class constructor and the concern for the fixture is defined by its namespace.
• Don’t force me to inherit from any base class to get BDD style tests working.  There is an interface ISpecification with one method Observe() to accomplish this.  A Specification base class is also provided for convenience.

For completeness, I am including the cliché BDD example of an account transfer fixture using this framework.

namespace Banking.Specs.FundsTransferSpecs
{
    public abstract class behaves_like_bank_account_transfer : Specification
    {
        protected readonly Account fromAccount;
        protected readonly Account toAccount;

        public behaves_like_bank_account_transfer()
        {
            fromAccount = new Account { Balance = 1m };
            toAccount = new Account { Balance = 1m };
        }
    }

    public class when_transferring_between_two_accounts
        : behaves_like_bank_account_transfer
    {
        protected override void Observe()
        {
            fromAccount.Transfer(1m, toAccount);
        }

        [Observation]
        public void should_debit_the_from_account_by_the_amount_transferred()
        {
            fromAccount.Balance.ShouldEqual(0m);
        }

        [Observation]
        public void should_credit_the_to_account_by_the_amount_transferred()
        {
            toAccount.Balance.ShouldEqual(2m);
        }
    }

    public class when_transfering_amount_greater_than_balance_of_from_account
        : behaves_like_bank_account_transfer
    {
        private Exception exception;

        protected override void Observe()
        {
            exception = ((MethodThatThrows)delegate
            {
                fromAccount.Transfer(2m, toAccount);
            })
            .GetException();
        }

        [Observation]
        public void should_not_allow_the_transfer()
        {
            exception.ShouldNotBeNull();
        }

        [Observation]
        public void should_raise_argument_out_of_range_exception()
        {
            exception.ShouldBeType<ArgumentOutOfRangeException>();
        }
    }
}

namespace Banking
{
    public class Account
    {
        public decimal Balance { get; set; }

        public void Transfer(decimal amount, Account toAccount)
        {
            if (amount > Balance)
            {
                throw new ArgumentOutOfRangeException("amount", amount,
                    String.Format(@"Cannot transfer ${0}.
                        The available balance is ${1}.", amount, Balance));
            }

            Balance -= amount;
            toAccount.Balance += amount;
        }
    }
}

Note the use of the namespace Banking.Specs.FundsTransferSpecs to denote the current concern – funds transfer.  Also note the use of how easily it is to reuse context setup code via constructor overrides.  Its nothing new as far as BDD goes, it just puts a nicer xUnit-style syntax on it.

It is a very simple project.  All credit goes to the authors of the previous three solutions.  I just cobbled together the best (at least what I think is the best) of those solutions.

The code for this (in cased you missed it before) can be found on the BDD Extensions project on Google Code.

Here is the official documentation on how to integrate BC3 with TortoiseSVN.

Here are my settings (on 64 bit machine):

Diff Viewer

"C:\Program Files (x86)\Beyond Compare 3\BComp.exe" %base %mine /title1=%bname /title2=%yname /leftreadonly

Put the SAME THING for both “comparing different revisions of files” and “comparing different revisions of properties”.

Merge Tool

"C:\Program Files (x86)\Beyond Compare 3\BComp.exe" %mine %theirs %base %merged /title1=%yname /title2=%tname /title3=%bname /title4=%mname

It got me to thinking of how I feel about this whole software thing.  I’ve been on a few interviews recently and one comment that I received a few times that stuck out in my head was “you are obviously very passionate about what you do.”  Hmm, does it really show that much? :,,)

I remember at one point in my life, I was dead-set on becoming an astronaut.  I was going to go to Embry-Riddle for a degree in Aerospace Engineering – then I was going to join the Air Force and eventually become an astronaut and go out and fly in space.  Ahh, I’m not really sure what happened to those plans.

I ended up going to LSU instead (mostly because I think I was too afraid of moving away from home) and I ended up majoring in Computer Engineering.  I remember the reason I gave for picking Computer Engineering was that I was good at working with computers and I knew I definitely did not want to do something with software – I wanted to work with hardware.  Ha!

At some point in college (near the beginning), I eventually found the need for money.  I wanted to buy things and most people accepted money for the things I wanted.  I didn’t want to get a job – who the hell wants to do work?  I eventually found that people would pay me to build websites for them.  After all, I dabbled in HTML and Flash back then and enjoyed building little websites.  This eventually lead to me learning PHP and later on .Net.

So I guess you could say I “fell into” the field.  But, really, who hasn’t “fallen” into whatever they are doing now?  Who says when they are a little kid “I want to write software when I grow up” or “I want to be an investment banker” or “I want to be a construction manager”?  No, you usually want to be a police man, or a fireman, or a doctor, or maybe even an astronaut when you are a kid.  When it comes down to it, we all just do what we are good at.

I still feel like I could be a million different things.  I used to love making little home videos (still do actually) – I could have worked somewhere in the movie industry.  I definitely had the test scores and brains to be a doctor.  I could have been a brain surgeon.  I might have even joined the Air Force and flew a fighter jet.  But I didn’t do any of those things, I wrote some software instead.

Bottom line is that I don’t see myself as a Software Developer.  I spend most of my time writing software, but I still feed my interests for other things with my hobbies.  I enjoy what I do and I am good at it.  And some people even pay me to do what I enjoy doing.  What more can somebody ask for?

The FormsAuthentication type is sealed and contains static members, so it is difficult to unit test code that calls its members. The interface and helper class below demonstrate how to create an abstract wrapper around such a type in order to make the AccountController code unit testable.

Ha, after experiencing the pain so many times in so many ways running into these sealed / internal classes when trying to unit test, I find it somewhat satisfying to see MS have to workaround their own issues.

I am just glad that it seems like the paradigm is finally shifting at Microsoft and that maybe, just maybe, we’ll start to see less internal sealed classes and more unit testable frameworks (unit testable from my – the user’s – point of view).

I need to display user-friendly 404 pages when a request is made for a controller that cannot be found.  Monorail provides a built-in way to handle this.  When faced with a request for a controller it cannot find, Monorail will look for a view named 404 in the rescues folder and render that.  That is good enough for most people, I guess.  It wasn''t good enough for me.  I needed my 404 view to use a layout (dynamically chosen based on some configuration settings) and to display some data.

To give you an example of what I am talking about, consider an ecommerce site.  When someone requests a page that doesn''t exist, you would want to show them a friendly error page that shows some featured products - some products that the user might be interested in.  We don''t want to turn the user away or show a sparsely populated page when our poor, unsuspecting user types a wrong URL.

First of all, I set out to use a custom rescue controller to solve all my problems.  Here is the relevant code:

[Layout("Default")]
public class RescueController : SmartDispatcherController, IRescueController
{
    public void Rescue(Exception exception, IController controller, IControllerContext controllerContext)
    {
        if (Is404(exception))
        {
            Handle404();
            return;
        }

        RenderSharedView("rescues\\general", true);
    }

    private bool Is404(Exception ex)
    {
        var httpEx = ex as HttpException;
        var mrEx = ex as MonoRailException;

        return (httpEx != null && httpEx.GetHttpCode() == 404)
            || (mrEx != null && mrEx.HttpStatusCode.GetValueOrDefault() == 404);
    }

    public void Handle404()
    {
        BindFeaturedProductsToView();

        Response.StatusCode = 404;
        Response.StatusDescription = "Not found";
        RenderSharedView("rescues\\404");
    }

    private void BindFeaturedProductsToView()
    {
        /* bind some data to the view here */
    }
}

I then append this little attribute to all of my controllers (or to the base class that all of my controllers inherit from - if you happen to have one of those...):

[Rescue(typeof(RescueController))]

That actually got me 90% of the way there.  A request for an action that didn''t exist on any controller would now be handled by my custom RescueController which could attach a layout and bind any necessary data that the 404 view needs.

The Devil is in the Details

Back to the original problem of this post - I need to be able to show this same view (and render it with the same logic) when a request is made for a controller that does not exist.  After digging through the Monorail source code a bit, and after a lot of trial and error,I eventually found a way to accomplish this.  First of all,I had to make my Handle404 method on RescueController public so that it could be accessible via a URL.  Then I ended up sub-classing MonoRailHttpHandlerFactory to handle the case of a missing controller.

public class CustomHttpHandlerFactory : MonoRailHttpHandlerFactory
{
    public override IHttpHandler GetHandler(HttpContext context, string requestType, string url, string pathTranslated)
    {
        IHttpHandler handler = base.GetHandler(context, requestType, url, pathTranslated);

        if (handler is NotFoundHandler)
        {
            //The default NotFoundHandler renders the 404 view in the
            //rescues folder if it finds one, otherwise it throws an exception.
            //We want to reuse our 404-handling logic in RescueController.
            context.RewritePath("~/rescue/handle404");
            return base.GetHandler(context, requestType, url, pathTranslated);
        }

        return handler;
    }
}

Note the use of context.RewritePath.  This keeps the requested URL the same in the user''s browser and simply reroutes the request internally to our RescueController.  We don''t want to just do a redirect to our RescueController as this would be very bad for SEO purposes.  We want to send a 404 status code to the user when they request our missing page - we just want to do it in a user-friendly way.

Gotchas

Make sure you update your web.config to use this new handler instead of the default Monorail one.  Also note that I am using routing to route /rescue/handle404 to the Handle404 action on RescueController.  If you were not using routing, you could change that URL to ~/rescue/handle404.castle or ~/rescue/handle404.rails depending on your configuration.  Overall, I like this solution very much.  It is very DRY and accomplishes everything I wanted to accomplish.