JQuery and Microsoft…Big News!

Scott Guthrie at Microsoft: http://weblogs.asp.net/scottgu/archive/2008/09/28/jquery-and-microsoft.aspx

Scott Hanselman at Microsoft: http://www.hanselman.com/blog/jQueryToShipWithASPNETMVCAndVisualStudio.aspx

John Resig from jQuery: ( http://jquery.com/blog/2008/09/28/jquery-microsoft-nokia/ )

Some snippets from ScottGu:

I’m excited today to announce that Microsoft will be shipping jQuery with Visual Studio going forward


Enough said.  I’ve been in love with jQuery since the first day I used it, been using it since.  Glad to see Microsoft making the move.    It’s been a powerful tool with asp.net mvc so far.  Very intuitive, easy to extend, etc…

The new ASP.NET MVC download will also distribute it, and add the jQuery library by default to all new projects.


We are really excited to be able to partner with the jQuery team on this.  jQuery is a fantastic library, and something we think can really benefit ASP.NET and ASP.NET AJAX developers.  We are looking forward to having it work great with Visual Studio and ASP.NET, and to help bring it to an even larger set of developers.

For more details on today’s announcement, please check out John Resig’s post on the jQuery team blog.  Scott Hanselman is also about to post a nice tutorial that shows off integrating jQuery with ASP.NET AJAX (including the new client templating engine) as well as ADO.NET Data Services (which shipped in .NET 3.5 SP1 and was previously code-named “Astoria”).


I do think this library is superior to what MS has used, and I was also curious why they did their own.  I figured it was because they couldn’t use Open Source.  So, I guess they will/can.  Good to see. Now… I think they’d be wise to refactor their own libraries to use jQuery/add on to jQuery (plugins, etc…)

I’ve personally built a few Html Ajax helpers, form validation helpers, etc.. for my asp.net mvc projects.  Plugins are easy to create and there is a tons of plugins available as well.

Great news!

ASP.NET MVC and Codebehind Files


I’ll throw my 2 cents in here:  I will agree that by default this shouldn’t be needed.  I’d rather add the ViewData model type to the aspx page itself.

What do I mean?

public partial class Employee : ViewUserControl<Core.Domain.Employee>

Quite honestly I think that is about all I use the code behind files for in the views.   There were some cases I would handle the page load event and bind to a Repeater, but those were typically not the approach I would use (I opted for a  HtmlHelper, ie. Html.Grid or Html.Repeater instead).

So, I like the idea of defining the ViewData<T> type in the actually aspx and then not require this additional code behind file.

Personally, I’d keep both available, making Tim Barcz’s technique the default

NHibernate MultiCriteria

Today I ran across an interesting problem – I needed to query to get counts after a process runs.  Obviously I can make two database calls, but I instead wanted to take advantage of NHibernate’s ‘MultiCriteria’ capability.  This will make one call to the database with the 2 queries vs. 2 database calls.  My example:


IMultiCriteria crit = NHibernateSession.Current.CreateMultiCriteria()
                    .Add(Restrictions.Between("ProcessedDate", lo, hi))
                    .Add(Restrictions.Between("ProcessedDate", lo, hi))
            IList results = crit.List();
            var companies = (IList)results[0];
            var employees = (IList) results[1];

            var companyCount = (int)companies[0];
            var employeeCount = (int) employees[0];



One queries CompanyDeposits and gets the rowcount, the other queries EmployeeDeposits and gets it’s rowcount.


For reference, check out Ayende’s post here as well 

(and thanks to Stefan for asking me about it, which made me want to go try it out… lol)

Cohesion & Coupling

Jeremy Miller’s MSDN article on Cohesion And Coupling.  Jeremy covers some of the OO ‘basics’ as part of his MSDN series ‘Patterns in Practice’ (see ‘The Open Closed Principle‘ article as well),  including

Decrease Coupling
Increase Cohesion
Eliminate Inappropriate Intimacy
The Law of Demeter
Tell, Don’t Ask
Say It Once and Only Once
Wrapping Up

As always, Jeremy does a good job explaining these software design fundamentals.

Architecture Layering Part II

Back awhile ago I made this post on Architecture layering.

Having a service layer in a ASP.NET MVC is a great thing!

Initially I was wrapping Actions with transactional attributes, making calls to the Dao objects, etc… Sure, the dao objects are being injected by my IoC container (Windsor) – which by the way, is very sweet, it’s so transparent that I forget who it creating the objects… I just use the interface… (that is another story)

I show a simple example below, but this sample doesn’t capture where I’ve been able to move business logic back into services – simplifying the controllers.   (Also, it cuts back on any duplication)

Simple example:


private readonly ICustomerDao CustomerDao;

ctor : MyCustomerController(ICustomerDao CustomerDao){ this.CustomerDao = CustomerDao;}  //injected

Then on a save:

public ActionResult Save(string id)
     …  CustomerDao.Save(Customer);

Instead I’ve moved this into a service layer – now the controllers know nothing about the data access layer:

public class CustomerService : ICustomerService
    private readonly ICustomerDao CustomerDao;
    public CustomerService(ICustomerDao CustomerDao){ this.CustomerDao = CustomerDao;}  //injected

    public void SaveCustomer(Customer customer)
         using(ITransaction tran = NHibernateSession.Current.BeginTransaction())


That is our service – it handles all transactions – where needed – in conjunction with the Dao objects

Now the controller gets an injected CustomerService rather than a CustomerDao.  Notice the Transaction attribute is no longer needed.


private readonly ICustomerService CustomerService;

ctor : MyCustomerController(ICustomerService CustomerService){ this.CustomerService= CustomerService;}  //injected

Then on a save:

public ActionResult Save(string id)
     …  CustomerService.SaveCustomer(Customer);


As far as the IoC goes, I’m doing that all within the Global.cs


ControllerBuilder.Current.SetControllerFactory(new WindsorControllerFactory(Container));


Then I use reflection to add the Dao’s and the Services’s to the container.  It uses Windsors ‘autowiring’ to handle creation based for dependencies.