Just last Friday, Rob Conery and I announced that we were working on a Commerce Starter Kit v 3.0, reviving the spirit of the CSK - “Sell your stuff, not your soul” (I always loved that tag line!). The project will be hosted on CodePlex. The current 3.0 checkins do not represent the current state of affairs, but a very interim state. It does show the architectural direction though. I also packaged up the final release of CSK 2.0 that Rob and I collaborated on so long ago for those that are interested. CSK 2.0 will not be actively supported moving forward. Support for CSK 3.0 will be done on the ASP.NET Forums.

This is a quick update on the current status and a preliminary schedule for releases, etc. Keep in mind that this is preliminary and subject to change (in either direction).

November 1, 2008: First drop of CSK 3.0. We’ll call this one a “Community Tech Preview” (CTP) and, in the tradition of CTP’s, it will represent a work very much in progress. We should have all of the major UI components of the site in place and, to some extent, functional. Well, catalog and cart are functional now, checkout … that may not be quite there on Friday’s drop, but I hope to have it there. I’d rather have this CTP release sooner than later to get feedback and participation from the community as early in the process as possible.

December 1, 2008: CSK 3.0 Beta 1. This will be a stable release and we’re targeting to have it feature-complete. But we’ll still be working on any bugs and tightening down the hatches.

January 5, 2009: CSK 3.0 Beta 2. Final beta of CSK 3.0. Again, a stable release, feature complete with few bugs (hopefully) left so we can concentrate on performance tuning and the like. (Note: there will be some tuning throughout the process, but this will involved a major push on tuning.)

February 1, 2009: CSK 3.0 RTM. ‘Nuff said.

I would love for this schedule to actually be too conservative. I really think it is. But … there’s lots to do and I do have other stuff on my plate as well, so I’m playing it safe. In between these milestones, there will be other drops as work progresses, with at least 1 interim release in between the dates here.

If you are interested in working on CSK 3.0 and can commit to spending some time on it (that second part is the hard one!), let me know. This is especially true if you have features that you’d like to see implemented; that’s the best way to get those features in there! Keep in mind though that, much as I would like to, I won’t be giving everyone commit rights … I will need to see some contributions, etc. first. The reality is that we can’t have a free-for-all on the source tree; that would be bad for everyone involved.

Well, I was looking over some old stuff on Rob Conery’s blog and came across a little rant about code behind vs. inline scripting. Now, I’m not gonna flame Rob – not at all – I just have a different viewpoint on the issue. I’m not going to say that Rob’s wrong or way off or anything like that – I have a ton of respect for him and his viewpoint – but I must also respectfully offer a different side of the story.

With that said, before I get into it, I do have to say that I agree with much of Rob’s defense of inline code. It is a perfectly valid way of doing ASP.NET pages, even today - it’s a “lifestyle choice”, like the choice between VB.net and C# (oh, I’m gonna get flames for that one, I’m sure). His responses to the arguments against inline code are dead-on.

One comment, though, that I’d like to add to the discussion of inline code vs. code-behind is that it promotes better separation. Done right, you have pure UI and design in the aspx markup. In the code-behind, you have the “glue” that ties the UI to the Business Layer. From a designer-to-developer workflow perspective, this is definitely a big bonus. You really don’t want pure designers writing or mucking about in code.

I also have to admit that I do have an aversion, personally, to inline code. It could be that it reminds me of ASP “Classic” code that I wrote so, so long ago. It was, to me, much harder to maintain and there was data access and logic and all kinds of ugly stuff all mixed up and jumbled up with the UI code. Of course, if you were smart about your ASP code – and I like to think that I was – you put a lot of this into include files. This, however, had it’s own issue that I like to term the “Magical Mystery Include”. Was it spaghetti code? No, not at all. But I didn’t find it tidy. Then again, on the flip side, there was no question about what was actually getting sent to the client – you had complete control over that, which is something that’s lacking in some of the higher-level ASP.NET controls (like GridView). And, Rob did have a point … too many developers have gotten so reliant on the abstractions brought about by ASP.NET’s server controls that they’ve forgotten their HTML and JScript – not a good thing.

With that said, I do take issue with his “example” using code-behinds. It was, I think, not truly representational of how one would accomplish the task with controls and code-behind. Back in college philosophy, we called this a straw-man argument. So I’m gonna set the record straight. I’m going to be implementing the same functionality – showing a list of objects returned from the BLL with one of the columns having a hyperlink to a page called “MyEditPage.aspx” passing the id to the page in the query string.

First, duplicating Rob’s example with an ObjectDataSource and GridView control:

    <form id="form1" runat="server" >
    <div>
        <asp:ObjectDataSource runat="server" ID="categoryDataSource" 
            SelectMethod="GetCategories" TypeName="Commerce.CSK.Web.Services" >
        </asp:ObjectDataSource>
    </div>
    <asp:GridView ID="catalogListing" runat="server" AutoGenerateColumns="False" 
        DataSourceID="categoryDataSource" enableviewstate="false">
        <Columns>
            <asp:HyperLinkField DataNavigateUrlFields="ID" 
                DataNavigateUrlFormatString="MyEditPage.aspx?id={0}" Text="Select" />
            <asp:BoundField DataField="ID" HeaderText="ID" SortExpression="ID" />
            <asp:BoundField DataField="Name" HeaderText="Name" 
                SortExpression="Name" />
        </Columns>
    </asp:GridView>   
    </form>

Look Ma! No Code!! That’s right folks, no code at all is required for this. Also, note that since we don’t need the ViewState, I’ve turned it off for the GridView control. But .. ViewState isn’t quite as bad as some folks think – it is compressed and, even better, it can be validated to help mitigate Cross-Site Request Forgery (something that’s getting to be more and more in vogue these days).

Still … I don’t have complete control over the HTML that is generated and sent to the browser. And this, my friends, is one of the reasons that I tend to avoid the DataGrid and prefer the Repeater. I like the Repeater – it is, in fact, my absolute favorite databound control. One of the responses that I get to that comment is that the Repeater doesn’t have a designer. Well, yes, that’s true but that doesn’t really bother me. I’m in the habit of doing about 95% of my ASP.NET in the markup view, not the designer. Call me old-fashioned, but I learned HTML back around 1994 or so, when all we had was Visual Notepad, and I still like to work directly with the tags. Which is why I love the split view in VS 2008; I get the best of both worlds.

Here’s the same thing, now using the Repeater control:

<form id="form1" runat="server">
    <div>
        <asp:ObjectDataSource runat="server" ID="categoryDataSource" SelectMethod="GetCategories"
            TypeName="Commerce.CSK.Web.Services"></asp:ObjectDataSource>
    </div>
    <asp:Repeater ID="catalogListing" runat="server" 
    DataSourceID="categoryDataSource"
        EnableViewState="false">
        <HeaderTemplate>
            <div>
                <table>
                    <tr>
                        <td>Option</td>
                        <td>ID</td>
                        <td>Name</td>
                    </tr>
        </HeaderTemplate>
        
        <ItemTemplate>
        <tr>
            <td><asp:HyperLink runat="server" NavigateUrl= '<%# "~/MyEditPage.aspx?id=" + Eval("ID") %>' Text='Select' /></td>
            <td><%# Eval("ID") %></td>
            <td><%# Eval("Name") %></td>
        </tr>
        
        </ItemTemplate>
        
        <FooterTemplate>
            </table> </div>
        </FooterTemplate>
    </asp:Repeater>
    </form>

Now … complete control over the HTML and still no code. I also want to point out that using the Hyperlink control provides a benefit that we don’t get with inline code – with the “~” format, the ASP.NET runtime will handle making sure that the link is correct from the current location, some that is very handy, even necessary, for user controls that could be running from a page anywhere in the application. The output will be identical (or darn close) to Rob’s example with inline code and even looks a little similar. But … I have to be honest … I’m not always too keen on using DataSource controls, especially if I don’t need the editing functionality that they provide. So … I could just take the ObjectDataSource out and write maybe 3 or 4 lines in the code behind to bind it all up. Easy enough. In that case, can you see all that is going on with the page in one shot? No, you can’t. You look at the markup and you see what the resulting page will look like … you see the design and that alone. To see the logic, you look in the code-behind. A nice separation of design/UI and code/logic and I like that. And, just in case you haven’t guessed, you’ll see quite a bit of that in CSK 3.0.

I am happy to announce a new Commerce Starter Kit. We’re calling it CSK 3.0, but it’s not based on the previous (CSK 2.0) codebase at all; it is a complete re-write from the ground up. Some of you probably remember when I first got involved in the CSK … that was WAAAAAY back in the days when ASP.NET 2.0 was all new and shiny. ASP.NET has, of course, moved forward quite a bit since then. We won’t be just upgrading the old CSK code base, but building a brand-spanking-new version, even though we’ll be calling it CSK 3.0. And … it will be in the same spirit as CSK - “shared source” and freely available to all. I will be reporting progress on this regularly, so you will want to subscribe if you want all the latest updates and news on the project.

This all started with a chat or two with my old buddy Rob Conery, the creator of the original Commerce Starter Kit. He’s here at Microsoft now and working on the MVC Storefront, a sample application that uses the ASP.NET MVC Framework (as the name implies). At the end of these chats, we thought we’d revive the CSK name and build a new version … with components and business logic based on the same components and business logic used for MVC Storefront but with a traditional WebForms UI. That’s right folks … it’s gonna share code with the site that Rob’s working on. Not only does it make life much easier, it also shows how the same core logic and functionality can be skinned with either MVC or WebForms.

Here’s the core stuff that is on the plate for this version:

Updates to the latest coolness: CSK 3.0 will be targeting ASP.NET 3.5 with SP1, so we’ll have all of the latest toys, including (of course!) Linq. :-)

Migration to common e-Commerce libraries: I mentioned this above; CSK will be using the same core business libraries and database as MVC Storefront, allowing you to easily switch between the two.

Localization support: Oh boy, I remember lots of folks asking for this with CSK 1.x and 2.0. The new CSK will be localizable out of the box. All of the product and category text and descriptions will be localizable. The goal is to also have most, if not all, of the static text on the pages localizable as well. That’ll be fun with resource files.

ASP.NET Dynamic Data Administration: The admin site will now be a separate web application so that there’s better isolation from the main web site. Of course, this could be installed as a virtual directory application under the main site but that won’t be necessary at all. You’ll easily be able to deploy it as a completely separate web site.

ASP.NET Web Application: This is the “old” (as in 1.x) model for web applications. While it’s not as easily changed while running (since you actually have to do a build), it does provide better start-up performance, something that became a complaint with CSK 2.0. Yes, yes, you could pre-compile the site (and I often suggested that folks do this) but with the web application model, that won’t be a separate step.

ASP.NET Ajax: This is all a part of the cool new toys, but I thought I’d highlight it separately. We’ll be using ASP.NET Ajax where it makes sense as well as the ASP.NET Ajax Control Toolkit.

Better composability: One of the things that I thought we could have done better with CSK 2.0 was to have a better composition model for the UI … for example, there were 2 or 3 different places to change a product list display … category list, search list, etc. This made it more difficult to maintain as fields were added or changes were made to certain core UI elements. These components will be separated into a series of User Controls, each with distinct, composable functionality. You want to change the view of a product in a list? Change it once and you’ll see it everywhere … search results, category listing, cart, etc.

Coupons: This was only partially implemented in CSK 2. Rob and I spent a couple of hours, both on the phone and over IM, and forth on how this would be implemented and I think it’s settled. The coupon system is going to be very extensible so that you can create any type of coupon that your heart desires. We’ll be including a couple of simple ones to get you started.

One of my key goals with this rev is simplicity. I want the UI (at least) to be as simple as possible … and I want it to be simple to re-skin the CSK to your own look and feel. To that end, I am using quite a bit more controls and data binding than were used in version 2.0 … everything, in fact, is in some sort of control or another. Additionally, I do want to highlight, as much as possible, the infrastructure of ASP.NET as well as the extensibility of this infrastructure. For example, for the category listing, I’m using a SiteMapProvider that builds a site map from the categories in the database. Believe it or not, this is actually quite easy to do and provides things like the SiteMapPath, which I do plan on getting in there.

I will need some help with this – in particular, I’d really like help with the following:

• Functionality – what features are essential and/or cool? What do you want to see in there? (No guarantees that it’ll make it, but if you offer to do it, it’s a lot more likely!)
• Design – Right now, I’m just stealing the design and layout from the MVC Storefront, converting it to use WebForms (so no MVC calls), etc. etc. etc. I call it the CASE methodology – Copy Always, Steal Everything. Now, I have the design skills of a dead toad, so redoing the design is simply out of the question. BUT … I would like to see it begin to diverge from MVC Storefront’s look. So any help that you might want to provide to do that would be very nice.
• Testing – Yes, we’ll have automated tests to catch a bunch of stuff, but manual testing and feedback is also needed, particularly when it comes to user experience.
• Migration – From CSK 2. I really don’t know if this is going to actually be possible and it’s certainly not something that I have on the list of “stuff to do” but if someone wants to volunteer to write a migration utility, that’d be cool with me.

I’m targeting to get the first, alpha “preview” version out in the next week or so and I’ll announce that here as well.

Continuing on the previous topic of Linq Performance … I’m now doing something a bit more interesting than just a “Select From”. All of the key conditions (machines, specs, methodology, blah blah blah) remain the same; no changes at all there. However, I’ll be digging around in filtering this time, comparing filtering between ADO.NET, Linq to SQL and, just for giggles, Linq to Objects and Linq to ADO.NET. Based on the previous results, I’m not using constructors for the custom classes, but rather property binding. The performance of the full property binding (rather than fields) is good and, let’s be honest here, that’s how you should be doing it anyway.

First, an overview of the different types of filters that I’m going to be running:

Find By First Letter: This will do a search/filter for Persons by the first letter of their first name … a LIKE query. Rather than getting the database all optimized and the query results cached, I select the first letter randomly from a cached copy of the table, but this is not included in the results. Yes, the query plan will be cached, but that’s normal and a part of the overall performance system that we want to test anyway.

Find By Non Key: This does a search/filter for Persons by First Name and Last Name. This uses an equality operator and will (most likely, though I didn’t check) return a single row. As before, the First Name/Last Name combination comes from a cached copy of the table and the values are randomly selected. As with the previous test, the query plan is cached and, again, that’s a normal thing.

Find Key: The last test does a search for a row by the primary key value. This does return a single row in all cases. The key to search for is randomly selected from a cached copy of the table.

For all of the tests, actual, valid values were used – hence the random selection from a cached copy of the table. Originally, this was not the case, but I quickly found that, in particular, the Linq tests that returned a single item would throw an exception if nothing was found – though this is likely because I used to First() method on the query return (the exception said that the list was empty). This would not have been an issue if I didn’t call this method and, instead, enumerated over the collection of 0 or 1 with the return.

For each of the test batches, five different methodologies were used.

Data View: This uses an ADO.NET DataView on an existing DataTable to do the filtering. The creation and filling of the table was not included in the test result. This is a method that you would use for cached data and tests the filtering capabilities of the DataView on its own.

DataSet FIlter: This uses the Filter() method to retrieve a subset of the rows. As with the previous, the table that is used comes prefilled.

Linq Detached: Essentially, this is Linq to Objects. The results come from the database and are then detached from the database, putting the results into a generic List<> class. As with the previous, creating and filling the list is not included in the results.

Linq To ADO: For something different, this filters a DataTable using Linq. Again, this is something that you’d do with a cache. And, yet again (I’m beginning to feel like a broken record here), the filling of the DataTable that is used for this is not included in the results.

Linq To Sql: This uses pure Linq to Sql, retrieving the results from the database and then returning the results. In this case, the cost of actually hitting the database is included in the results. As you can, I’m sure, imagine, this is the only test where the query plan caching made any difference at all; the rest of the tests were working on data in memory.

I did not include results where a DataSet returns results directly from the database; the performance characteristics of this with respect to the Linq To Sql tests would be the same as in the previous selection tests.

So, without further ado, the results:

I have to say, I found the results quite interesting. There are some pretty wide variations in the methods, depending on what you are doing. I was also surprised to see that the Find By First Letter had the worst performance for Linq Detached … this was not what I was expecting and not something that I had seen in previous test runs on a different machine (but that was also testing against a Debug build rather than a Release build). The average time for the DataSet Filter was very highly impacted by the Find By Non Key batch … this is just really bad with DataSets. Find Key for the dataset was very fast though … so much so that you can’t even see the bar in the chart; this is due to the indexing of the primary key by the DataSet. Linq Detached was hurt by the Find By First Letter batch; my theory is that this is due to string operations, which have always been a little on the ugly side. Other than that, the find performance of Linq to Objects was quite good and finding by key and by non-key fields were little different – and this difference would, again, most likely be due to the string comparison vs. integer comparisons.

Ever since I posted about .Net Dojo, I’ve had quite a few requests to have it elsewhere. Well, after seeing Pablo’s Day of TDD and how awesome that was, I got this little notion that it might be cool to do .Net Dojo in Austin. And … also … well, this format was kinda new and I wanted to give it a trial run or two before I started doing more. So, with that said, we’ve got the very next .Net Dojo scheduled for Austin … our first one out there! It’s going to be the same as the last Houston event and, judging from the feedback that I got on the Houston Dojo, it’s gonna rock!

Here are the details:

When: November 3, 2008  1:00 PM – 5:00 PM

Where: Microsoft Austin Office

Overview:
Windows Communication Foundation (WCF) is Microsoft’s strategic technology for building distributed, connected systems. Initially released with .NET 3.0, it has been significantly enhanced in .NET 3.5 to support the various web programming models including SOAP, POX, WS-*, REST and RSS/Atom syndications.  Topics covered include: SOA basics, WCF architecture, WCF bindings, hosting WCF services, WCF behaviors, WCF security and some design best practices.

What you will learn:
Stephen Fulcher will guide you through a combination of lecture and hands-on labs where we will learn how to implement the various web programming models with WCF. Specifically, we will cover SOA basics, WCF architecture, WCF bindings, hosting WCF services, WCF behaviors, WCF security and some design best practices.

Prerequisites:
To fully participate in this workshop, attendees will need an open mind and a laptop with:
-  Visual Studio 2008 Professional or higher (Trial is OK) with Service Pack 1
-  Windows PowerShell 1.0 (optional, but recommended)
-  Microsoft SQL Server 2005 Standard or Express
-  A CD-ROM drive to load additional components and lab files.

Now that you have the details, I know that you want to go here and register now. Hope to see y’all there!