LINQ Love

I am in the midst of my first full-fledged application that has been designed and architected with the notion that the majority of the data access will go through LINQ-SQL.  The first thing I did was add a logging layer on top of the DataContext (by setting the Log property to  a custom Stream object) so that I could see exactly what the SQL looked like from various LINQ queries.

I was pleasantly surprised.

The SQL code that LINQ creates isn't ground-breaking - I've had occasion to write dynamic SQL in my time so that I could juggle the join order and a bunch of other factors in a complex search algorithm, but I don't think I'll be writing another one anytime soon; LINQ just makes it too darn easy to do the stuff that really was just time-wasting code before. 

Also, it means my service or binding layer can make whatever kinds of calls it wants to.  No longer do I have to decide at an application level whether I am going do sorting and paging at the database or application level: the application can decide for itself what the appropriate behaviour will be.

My questions about architecture are different now, though.  Where I used to have a static data access layer that piped calls to and from my stored procedures, now I have a LINQ layer, but I can also embed lots of business logic in that layer.  For instance, I can add logic that check that an Order object must have at least $50 worth of OrderItem objects to qualify for a certain discount.  This logic could be programmed into the LINQ layer using the partial methods that are defined, but it doesn't feel right - normally with a Static layer we can just pipe one call to another without having to worry about something like the DataContext, but with LINQ, we don't want to the actually query to execute until the last possible moment: when it needs to be used.

Any thoughts on this one?