For the past 2-3 months we have been working hard to deliver (no pun intended) an online ordering system for Debonairs. Basically, we we were tasked to produce a website and mobi site which would enable Debonairs’s customers to order a pizza using their favourite internet browser. The sites went live a few weeks ago and I thought it would be useful to put together a short blog post describing the solution from a technical perspective.

Debonairs Pizza

Both the website and mobi site were developed using Microsoft’s ASP .NET MVC 2.0 framework with some slight modifications to the vanilla setup. We chose to use Spark as our view engine. Spark’s syntax is declarative and resembles HTML which enables us to integrate code seamlessly (i.e. our views don’t evolve into spaghetti code). This is not the sole advantage of using Spark, I would recommend taking a read through the documentation to realise the more important benefits. This is not the first project we’ve integrated Spark with, and we continue to enjoy working with it.

In terms of client side scripting, we used jQuery as our JavaScript library. Combres (an open source project hosted on Codeplex) was implemented at the backend to ensure that resources such as JavaScript and CSS were minified and compressed before being served to a customer’s browser. Furthermore, Combres enables us to easily update our JavaScript/CSS references which ensures that the latest version of the relevant resources are always loaded.

For the mobi site, we stuck with MVC but ensured that the markup produced by the server was XHTML-MP compliant. Given the nature of the mobile landscape, we were required to support a large number of internet enabled devices ranging from smart phones (such as the iPhone) to the hugely popular Samsung E250. For Mobile Researcher we use a library called Device Atlas which enables us to detect the type of device accessing the site and provide information regarding key capabilities. Given our experience with the product we used the same library on the Debonair’s mobi site. Images are automatically scaled and cached for devices accessing the site which ensures the site’s look and feel remains consistent no matter what resolution the relevant device sports. In time, we may begin enchancing the site for specific devices such as iPhones and Blackberrys.

For persistence we chose SQL Server 2008 R2 Web Edition. We have extensive experience working with both Microsoft SQL Server and MySql, however, we wanted to utilise Windows Workflow 4.0 as part of the solution and we didn’t have time to look at writing a custom MySql persistence service for the workflow engine. In any event, our selected ORM (LLBLGEN) enables us to target any number of database technologies so theoretically, we could switch over to MySql in the long term without too much work. From a code perspective, we implemented the repository pattern using custom LLBLGEN templates. At the repository level, queries were developed using LLBLGEN’s LINQ engine.

Windows Workflow 4.0 was used to handle longer running processes such as those invoked when placing an order. Once an order is validated, the order is serialised into XML and posted to a third party POS gateway which performs further validation and propagates the order down to the relevant store. There are number of failure points involved in this process hence the use of Windows Workflow. If the order is not successful (whether it reached the third party gateway or not) an SMS is sent to the relevant customer informing them of the failure. As you can imagine, there are a number of issues that could cause this to happen including network connectivity failures to the the third party gateway, connectivity problems between the stores and the gateway etc. We wrote a custom Workflow Application Manager that manages persistence and execution of Workflows which means the system is resilient against system reboots etc.

A Windows Service was developed to host the workflow runtime and provides the host for workflow execution. Besides order processing, the service handles menu synchronisation, store connectivity tracking and communication (email/SMS) services. To facilitate communication between the web and mobi-site, we used NServiceBus which leverages MSMQ. NServiceBus enables us to deliver messages to the Windows Service in a transactional context which is obviously critical.

As far as unit testing goes, we used a number of frameworks and libraries to facilitate the unit testing process. For the core testing framework, we used NUnit. For our mocking library we chose Moq. Moq simplifies the mocking process considerably as it exposes a fluent API. If you haven’t heard of Moq I seriously recommend checking it out.

Right now both sites are humming away on IIS 7.5. There is a lot more to come with a number of key features still in development/testing, the main being the ability to pay for an order using your credit card. All in all, the
implementation process has has been an exciting experience which has allowed us to leverage a number of new and useful technologies. Without resorting to butchering the idiom ‘the proof is in the pudding’, please think about placing your next order for a Pizza using one of the sites mentioned – we would really appreciate your feedback.

If you have any questions, comments or suggestions please free to give me a shout.


9 Responses

  1. Fantastic info – weldone on going live!

  2. Out of interest why did you pick NUnit over the other unit test frameworks?

  3. Rohland says:

    Familiarity I guess. We have used NUnit for some time now and are pretty happy with it. In time we may start looking at other frameworks, right now we are so busy with the operational stuff it’s difficult to make a decision to spend time and tinker with something which already works for us.

    Thanks for the congrats. It is still early days and there are still a few teething issues with the order process but we are pretty happy with what we have been able to achieve in a relatively short time frame.

  4. Mark Tamall says:

    That sure is a lot of tech to order a pizza! :) Did you use MOQ to mock the LLBLGen DataAccessAdapter? If not, how did you go about unit testing methods which use the DataAccessAdaper?

  5. Rohland says:

    Hehe, after writing this post I thought the same thing :)

    We went as far as mocking the repositories which utilise LLBLGEN’s LINQ context. Beyond that we didn’t test the internals which would include the DataAccessAdapter.

  6. Denis says:

    hi, very good article. Just wanted to know how you implemented the custom workflow persistence service. We also are using an orm tool that allows our products to run on multiple databases (hence we cant be limited to only the sql ex schema) pls assist

  7. Rohland says:

    We used a custom workflow manager as opposed to the WorkflowServiceHost. We still used SQL Server and the base SqlWorkflowInstanceStore so I’m afraid I won’t be able to help you out. Like you, I was doing some research the other day to find out what it would take to implement Windows Workflow on a different database server (MySQL etc.) but couldn’t find any documentation on the subject. Annoying.

  8. Theveshen says:

    Hello Rohland.

    Well Done on going live, please advise if my my business wants to do something similar what are time lines and process

  9. Nadia says:

    Hi Rohland

    Do you know if there’s been an increase in sales due to the mobisite – if so how much ?

Leave a Reply