Inspired by Rob Conery’s great work on his MVC Storefront screencasts, I decided to look into his Pipes and Filters implementation and attempt to create my own. Although there was a lot of critical commentary on some of the design decisions, I found myself very intrigued by this fluent interface implementation. I haven’t referenced back to the specific code samples so if it differs significantly, please keep in mind that this was certainly inspired by it.
A very nice feature of Linq to Sql is that it delays query execution until you start enumerating over the collection. This lets the developer build complex queries programatically and make only one call to the database. Linq to Sql is smart enough to derive the resulting T-SQL to produce your result set.
For this scenario, let’s assume we want to select blogs that are tagged with specific tags and the blog name starts with a certain string. Below we can see a simple entity model that shows the relationships among the Blog, BlogTag and tag tables.
Let’s keep the domain-specific language for our extension method names. I’ll create two extension methods: “AreTaggedWith” and “BlogNameStartsWith”. The former will accept a string array of tags and the latter will accept a string parameter. Both of these methods extend the IQueryable<Blog> interface and return the same.
We can then “daisy-chain” these all together to create are linq query before actually enumerating (and therefore executing) the final query. This will produce a nice looking, fluent interface for our data access layer.
Using SQL Server Profiler, we can take a look at the query that Linq to Sql actually generated and how it is executed with input parameters and all.
Looking at the query above, I’d love to hear your thoughts on whether this is the most tuned query for this scenario. Did Linq to Sql did a good job generating the query?
Part of a project I’m working on requires users to tag certain items. These tags are subscribed to by other systems and are also used to provide some neat auto-complete features for other inputs throughout the site. Since new tags can be added by a user, I want to make sure that when the tag is added, the capitalization is in Title Case. Here’s a quick demonstration of how to use mbUnit’s RowTest feature to allow you to test more scenarios with less code. First, lets take a standard, single scenario test:
As you can see above, I am setting an expectation on my repository that when it is called, it will insert the original input as a properly formatted string. The formatting will be implemented within my service class. Running this yielded a filed test – RED (good!).
Now let’s implement this feature:
I decided to create a string extension method which uses the little known ToTitleCase method of the TextInfo class. This method accepts a string and returns it as a title-cased string. Also note how we can split the dot-notation across lines making it much cleaner. Below is the actual service call which will format the string and call my IRepository method:
After implementing this, I went back to the test and ran it. Success!
At this point, something occurred to me. The tag name “test tag” is easy to verify. However, how will this implementation handle capitalization rules? For example, if I enter “LCD Repair” as a tag, it should NOT format it to “Lcd Repair”. This is where the RowTest feature shines. Instead of writing a new test for each of these scenarios, I just converted my “Test” attribute to “RowTest” and changed the method signature.
As we can see, the method signature matches the individual Row parameters. When we run this test again, it executes the test once for each row. When you actually look at the test runner, it shows up as 3 individual tests so each row can fail independently.
Hope this helps!
I recently was overhearing the conversation a colleague of mine was having about debugging a large Win Forms application. It seems he was jumping through some major hoops to be able to debug the application. Without getting too much into the architecture of the solution, it was instantiating other applications through a messaging system backend to communicate between apps. In order to debug it, the team was using some code workarounds to kill processes, muddle around with new threads and processes, create a new process in debug which then impersonates some other process etc. At least that’s what I think was happening.
This kind of debugging situation can be solved easily by using the “Attach to Process” debug functionality in Visual Studio. I was surprised that the team didn’t know about this feature so I wanted to post a quick “How-To” on using it so others can benefit from it.
A couple of prerequisites must exist in order to attach to a running process.
(1) The source must match the running application
(2) The running application must have been compiled in debug mode
It’s fairly simple. When you open up the source in Visual Studio, just navigate to the Debug menu and you’ll find a menu item “Attach to Process”.
When you select this, you will be presented with a window that shows all your running processes. Simply click on the process you want to attach to and you’re done.
If you’re debugging a web application and using IIS to debug, you can even attach to the ASP.NET worker process “aspnet_wp.exe”. This will allow you to break on external requests to your web app. If you’re using the ASP.NET development server, you’ll also find this on the list of processes you can attach to.
Hope this helps.
There was a recent post on LessThanDot to create a small application to find all the “Friday the 13th’s” occuring in a range of dates. Here is my simple solution to the challenge. I also made it flexible enought to find any occurrence of a day / day of week combination within that range. It runs surprisingly quick even when looking over the next 500 years.
Also, if you like my color scheme, I’ve made it available for download here.
My first “official” blog post and what exciting news to report! First of all, a big thank you is in order to Joe Stagner for helping me set this up. It’s a huge honor to have found a new home here.
Scott Guthrie has just announced that Microsoft will be delivering the source code to the .NET 3.5 framework later this year. It will be available as a standalone install so you can actually use any text editor to view it. This is major news. It is really just putting it all out there. You’ll even be able to step-through the framework code from VS 2008.
What a way to kick-off the new blog. I’ll be transferring my existing blog entries in the next days and I look forward to hearing from everyone.