Hadn't been writing a lot lately, even though exciting things were happening, especially in the AspView front (stay tuned).

Why, you ask?

Well, I'll tell you why.

Had a tooth implant on Sunday, and the antibiotics and pain killers were distracting me. To the point of loosing time over extremely stupid mistakes.

Anyway, I hope to fell better next week, and to have some spare time for writing some interesting stuff.

I feel so stupid.

Just spent almost two hours trying to figure out why a SQL query wasn't running.

I kept getting "Incorrect syntax near 'RowNumber'" error message.

I was under the impression that my SQL syntax was ok, and tried various changes to the way I was invoking the query, but alas, nothing worked.

Then I just copied the raw query into SQL Manager, just to see the next snippet (the colouring, or lack of, was pointing this out for me):

WEHRE RowNumber BETWEEN @First AND @Last

WEHRE the hell was my head?

Usually I won't just link to a post, however go and read this post from Andre Loker is is a good one, and the title says it all.

A quote from there, just as appetiser:

if you use ReSharper (and you should) you can skip the ViewAtDesignTime class altogether and just use the AspViewBase class (or a derived class) in the view. ReSharper will still provide Intellisense. The list of members is much more reliable as those members will definitively be available during compilation.

All in all, Andre's blog is good reading. Added to my rss-reader of choice.

Have just came back from my talk, given for The Developers Group in Microsoft's Victoria offices, London UK.

Took me a bit to find the place, as the building does not say "Microsoft" on the outside (as opposed to the offices in Israel).

The presentation went pretty much ok, considering it was my first time actually presenting in English, in front of an English crowd, and considering I had a PC malfunction that has forced me to recreate the Demo project, on the train today ... Just finished it up 5 seconds before connection the laptop to the projector.

I didn't manage to squeeze in some of the parts that I wanted to, like JSONReturnBinder and Windsor integration, and like Unit-Testing controllers and views, but I do hope that I managed to do justice with this wonderful stack, within the limited time and my horrible English ...

Unfortunately, I missed the post-meeting-pub-thing as I just happened to leave the place last and didn't see where everyone did go, so if you were there and has some questions, please do not hesitate to leave them here as comments.

Anyway, as promised, here are the slides and the demo project.

If you are using git, and have a git-hub account, then you would be able to follow the demo project's source at http://github.com/kenegozi/monorail-aspview-demo/tree/master

Have fun.

P.S

I'd like to thank Jason from The Developers Group, and Nina from Microsoft, who have helped with the administration part of things. Everything went smooth despite my late arrival. I'd also like to thank the attendees for their patience and listening. I hope you've enjoyed it, I definitely have :) 

I always need to look it up, so I might as well put it here for future reference:

What is a DetachedCriteria?

This is an ICriteria object, that is detached from any ISession, therefore is suitable to be passed around as a specification that is being built up dynamically.

Why would I want to clone it?

Well, say I want to run two similar queries (same WHERE part) but with a different projection or aggregation. For example - when fetching a paged collection, you'd want to create the spec criteria, then add Count projection on A to get the 'total number of records' ,and add the paging restrictions (sort, then from row 101 take 10 records). Now if you'd try to add the restrictions to the criteria to which you have already applied Count on, and error would occur.

Solution:

There's CriteriaTransformer class, which holds a few useful static methods, amongst them, Clone(DetachedCritetia):

DetachedCriteria spec = DetachedCriteria.For<Whadever>()
   ...; <= setup criterions
 
DetachedCriteria countCriteria = CriteriaTransformer.Clone(spec)
    ...; <= setup the count projection
  
DetachedCriteria pagedCriteria = CriteriaTransformer.Clone(spec)
    ...; <= setup the paging
 
 
ICollection<Whadever> stuff = whadeverRepository.FindAll(pagedCriteria);
int total = whadeverRepository.Count(countCriteria);

One of the methods of querying the DB when using NHibernate, is to issue HQL queries. HQL stands for "Hibernate Query Language". It has a SQL-like syntax and is very intuitive for people with SQL background.

The way this works is that NHibernate 'compiles' the HQL query into SQL, and then issues the SQL query (using ADO.NET's facilities) to the DB.

Sounds pricey?

enter Named Queries.

now these are HQL (or SQL) queries, each has a name (obviously), that are been supplied to NH through the mapping. The queries are being translated and cached as IDbCommand objects as part of the framework initialisation, which mean that you get rid of the HQL->SQL overhead throughout the life of the process.

One other major benefit, is that the mechanism to actually execute these named queries, does not differentiate between HQL and SQL queries (for the simple fact that these queries have already been transferred to SQL at runtime). That gives you the possibility to replace HQL queries into tighter SQL queries (with the same parameters and which returns the same resultset) should your DBA figure out a better one.

But if you're using ActiveRecord, you usually do not have direct access into the mapping (.hbm) files. So how would you use named queries with AR?

enter HqlNamedQueryAttribute (not such a great name, as I did state that it would also work for SQL queries).

So, for an example, on this blog's source code, within PostRepository.cs you'd see this code:

...
 
#region queries
[assembly: HqlNamedQuery(Queries.FindPostsInArchive, Queries.FindPostsInArchive)]
[assembly: HqlNamedQuery(Queries.FindByUrlFriendlyTagName, Queries.FindByUrlFriendlyTagName)]
namespace KenEgozi.Com.Domain
{
    internal partial class Queries
    {
        internal const string FindPostsInArchive = @"
                from Post p
                where 
                    year(p.Lifecycle.CreationDate) = :year and
                    month(p.Lifecycle.CreationDate) = :month 
                order by p.Lifecycle.CreationDate desc";
        internal const string FindByUrlFriendlyTagName = @"
                select p 
                from 
                            Post p 
                    join    p.Tags t
                where t.UrlFriendlyName like :urlFriendlyTagName
                order by p.Lifecycle.CreationDate desc;";
    }
}
#endregion
...
 
        public ICollection<Post> FindInArchive(int year, int month)
        { 
            return session
                .GetNamedQuery(Queries.FindPostsInArchive)
                .SetParameter("year", year)
                .SetParameter("month", month)
                .List<Post>();
        }
...

Queries class is marked as partial, as other queries might be presented on other repositories or services that would need to add more named queries. I considered grouping of queries into groups by the using repository, or by aggregate roots, but the thing is - having all of the queries under the same namespace helps discoverability, and helps with preventing duplications

Wow, it feels like yesterday.

On last December, the feedburner's subscribers count on this blog has first reached 200.

Two weeks ago I've noticed that:

Silly, useless, but pats a certain shoulder nonetheless.

Over two year ago, I have posted about the un-orthodox box model that IE6 is using. 

Yesterday I saw that Ohad Aston (an Israeli Web developer who blogs in Hebrew at the Israeli MSDN blogs site) has written a Hebrew explanation to the same phenomena, so if you do web, especially using ASP.NET and can read Hebrew, I recommend that you take a peek. And if you're there, subscribe to his RSS. I did.