Damian Brady's Blog

Recently, I’ve been telling anyone who will listen that you should consider writing an HTML5 web app rather than a native mobile app.  The advantages are many and the list of things you can’t do grows smaller by the day.

I spoke on the topic at DDD Sydney earlier in the year, and more recently at Web Directions “What Do You Know” in Brisbane.  If you’d like the slides, they’re available at http://www.damianbrady.com.au/dyrnaa and http://www.devnewsreader.com/about.html respectively; complete with demos.  Check them out – I’d love your comments.

Why choose web apps over native apps?

There are a lot of reasons, and most are obvious.

1. Users are always on the latest version – no support of old versions
2. You only have to implement it once, in one language (counting HTML, CSS, and JS as one language of course)
3. You can choose what to charge and how to charge it
4. Done properly, web apps work on all devices – even those that don’t exist yet

But they’re slow!

Well no, not necessarily.  I blame Facebook for this misconception.

Facebook famously released an HTML5-based app for iOS and then ditched it in favour of a native app to squeeze more performance out. After all the reporting, the emergent mainstream view was that HTML5 apps simply couldn’t perform.  In reality, the new release was a refresh using a technology closer to the metal as a reaction to consumers screaming out for performance above all else.  Let’s face it, Facebook is not a trivial app in terms of bandwidth and content. There’s a fair bit going on with photos, chat, notifications, etc.

Could Facebook have made the app faster while still using HTML5? Almost certainly, and if they’d leveraged newer HTML5 capabilities as they became available, there definitely would have been improvements.

But would it have appeased the masses? Maybe, but we’ll never really know.

But web apps can’t do X!

Quite possibly not, no.

Well… unless you’re talking about using touch events, orientation, geolocation, hardware-accelerated graphics, local data storage, offline operation, home-screen icons, audio and video, sending emails or making phone calls. So probably yes… yes they can.

Sure, there’s gaps in there. A web app can’t use your phone contacts, it can’t play your music, and it can’t (quite) use the camera.

…Yet

Yet?

There’s a very definite trend in the world of HTML and browsers.  Each new browser or mobile OS version slowly chips away a bit more at the list of things a web app can’t do.  Surprisingly, Apple seems to be leading the way to a degree in the mobile space; enabling more and more HTML5 features in Safari with each release.

I say “surprisingly” because Apple has a very captive market in terms of native apps. True or not, the perception exists that neither Android nor Windows Phone have the same quality of apps available in their stores. Certainly they don’t have the quantity. Why then would Apple implement functions in Safari that pave the way for native-quality web apps?  It’s a good question, and I’m not sure I have the answer. Maybe it’s just the constant drive to stay in front.

Grooveshark

Very recently, Grooveshark rolled out a fully-functional HTML5 version of their site that works beautifully on mobile devices.  They’ve been plagued by problems getting native apps into the official app stores, and this option allows them to bypass the problem altogether.

It’s a truly impressive piece of engineering. If you have a … well… anything… I strongly suggest you go and try it out.  There are some amazing features. For example, (On iOS at least) you don’t even have to keep the browser window open for the music to keep playing.

One small thing… I’d love to see them implement some of the meta and link tags that Apple has made available for iOS devices.  For an example, try adding http://www.devnewsreader.com to your home screen on an iPhone or iPad (warning, it’s quick-demo quality).

Despite being a company that focuses on something not traditionally offered via a web page (streaming music), Grooveshark has chosen HTML5 as the right way to go.  Before sinking time and money into developing native apps for multiple platforms, it’s worth considering whether your app might be a good candidate for a web app as well.

Grooveshark may not be the first high-profile name to try to escape the walled-garden of native apps, but moves like this definitely show the blood in the water (pun totally intended and awesome).

You may be familiar with my previous posts describing the implementation of design patterns for Entity Framework.  It started with using generics for lookup tables, and followed with a generic CRUD repository.  This strategy follows along with our SSW rule, Do you use the Repository Pattern for data access.

In the lead up to SSW’s recent Enterprise MVC course, I had lots of discussions with Adam Stephensen and Eric Phan about whether we could do a better job with this pattern.  We’ve come up with what we think is a great solution that includes the Unit of Work pattern as well.

We felt it was really important to separate the domain models, the repositories, and the context; a separation that’s not made by Entity Framework. Doing so gave us some really important benefits.  Testing is made much easier.  For one, we can mock our context enabling us to test our repositories without going back to the database.  We can also mock the repositories to test the code that calls it.

A quick shout-out to Adrian Clark who suggested this separation in the comments last time.

We also used Inversion of Control to inject a context into the repository.  We could have had a reference to each of our repositories in our context, but inverting this relationship meant that we only needed to instantiate those repositories we were actually using.  It means less overhead and a looser coupling between the context and each repository.

First, we create our IUnitOfWork and our IGenericRepository.

public interface IUnitOfWork : IDisposable
{
    DbSet<TEntity> Set<TEntity>() where TEntity : class;

    int SaveChanges();
}

public interface IGenericRepository<TEntity>
  where TEntity : class
{
    IQueryable<TEntity> Select();

    IEnumerable<TEntity> GetAll();

    IEnumerable<TEntity> Where(Func<TEntity, bool> predicate);

    TEntity GetSingle(Func<TEntity, bool> predicate);

    TEntity GetFirst(Func<TEntity, bool> predicate);

    void Add(TEntity entity);

    void Delete(TEntity entity);

    void Attach(TEntity entity);

    void Dispose(bool disposing);

    void Dispose();
}

Then, we create an interface for our specific context. In this example, we have a context with a set of customers. This context is essentially a unit of work, so we’ll inherit that interface.

public interface ICustomerContext : IUnitOfWork
{
    DbSet<Customer> Customers { get; set; }
}

Next, we’ll create a concrete GenericRepository instance. This is very similar to the version in my previous post, but take note of the repository that takes a context. We use this to inject our Unit of Work.

public class GenericRepository<TContext, TEntity> : IGenericRepository<TEntity>
    where TContext : IUnitOfWork
    where TEntity : class
{
    protected TContext _context;
    /// <summary>
    /// Constructor that takes a context
    /// </summary>
    /// <param name="context">An established data context</param>
    public GenericRepository(TContext context)
    {
        _context = context;
    }

    public IQueryable<TEntity> Select()
    {
        return _context.Set<TEntity>().AsQueryable();
    }

    public IEnumerable<TEntity> GetAll()
    {
        return _context.Set<TEntity>().AsEnumerable();
    }

    public IEnumerable<TEntity> Where(Func<TEntity, bool> predicate)
    {
        return _context.Set<TEntity>().Where(predicate);
    }

    public TEntity GetSingle(Func<TEntity, bool> predicate)
    {
        return _context.Set<TEntity>().Single(predicate);
    }

    public TEntity GetFirst(Func<TEntity, bool> predicate)
    {
        return _context.Set<TEntity>().First(predicate);
    }

    public void Add(TEntity entity)
    {
        if (entity == null)
            throw new ArgumentException("Cannot add a null entity");

        _context.Set<TEntity>().Add(entity);
    }

    public void Delete(TEntity entity)
    {
        if (entity == null)
            throw new ArgumentException("Cannot delete a null entity");

        _context.Set<TEntity>().Remove(entity);
    }

    public void Attach(TEntity entity)
    {
        if (entity == null)
            throw new ArgumentException("Cannot attach a null entity");

        _context.Set<TEntity>().Attach(entity);
    }

    #region IDisposable implementation
    private bool disposedValue;

    public void Dispose(bool disposing)
    {
        if (!this.disposedValue)
        {
            if (disposing)
            {
                // dispose managed state here if required
            }
            // dispose unmanaged objects and set large fields to null
        }
        this.disposedValue = true;
    }

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }
    #endregion
}

Next, we’ll create a concretion for our context using Entity Framework. We’ll inherit DbContext as well as implementing ICustomerContext, and we’ll create both an empty constructor and one that takes a connection string so we can connect to a specific database.

public class CustomerContext : System.Data.Entity.DbContext, ICustomerContext
{
    public CustomerContext() { }

    public CustomerContext(string connectionString) : base(connectionString) { }
}

And that’s all we really need to do.

When we use it, we have to make sure we refer only to our interfaces so we can replace them later if need be.

private ICustomerContext _context;
private IGenericRepository<Customer> _customerRepository;

Ideally, we’d be using Dependency Injection to inject our concretions at runtime, but here’s an example of how you would do it.

_context = new CustomerContext();
_customerRepository = new GenericRepository<ICustomerContext,Customer>(_context);

From there, we can do whatever we need to do with the objects in our repository, and just call SaveChanges() on our context when we’re done. For example:

public ResetCustomerLastLoginDate(int customerId) {
    var customer = _customerRepository.GetSingle(c => c.CustomerId == customerId);
    customer.LastLoginDate = DateTime.Now;
    _context.SaveChanges();
}

I wrote a post a while ago about using Generics for lookup tables in Entity Framework and I suggested that the idea could be extended to include all objects and CRUD operations.

Well, I’ve put together a generic Repository that can be used in your project to give you a consistent base class for all your repositories. It’s quite long, so sorry about that.

This implementation follows our SSW Rule, Do you use the repository pattern for data access.

public class DataRepository<TContext> : IDataRepository<TContext> where TContext : ObjectContext
{
    // Cached ObjectSets so changes persist
    protected Dictionary<string, object> CachedObjects = new Dictionary<string, object>();
    protected ObjectSet<TEntity> GetObjectSet<TEntity>() where TEntity : EntityObject
    {
        var fulltypename = typeof (TEntity).AssemblyQualifiedName;
        if (fulltypename == null)
            throw new ArgumentException("Invalid Type passed to GetObjectSet!");
        if (!CachedObjects.ContainsKey(fulltypename))
        {
            var objectset = _context.CreateObjectSet<TEntity>();
            CachedObjects.Add(fulltypename, objectset);
        }
        return CachedObjects[fulltypename] as ObjectSet<TEntity>;
    }

    protected TContext _context;
    /// <summary>
    /// Constructor that takes a context
    /// </summary>
    /// <param name="context">An established data context</param>
    public DataRepository(TContext context)
    {
        _context = context;
    }

    /// <summary>
    /// Constructor that takes a connection string and an EDMX name
    /// </summary>
    /// <param name="connectionString">The connection string</param>
    /// <param name="edmxName">The name of the EDMX so we can build an Entity Connection string</param>
    public DataRepository(string connectionString, string edmxName)
    {
        var entityConnection =
            String.Format(
                "metadata=res://*/{0}.csdl|res://*/{0}.ssdl|res://*/{0}.msl;provider=System.Data.SqlClient;provider connection string=",
                edmxName);

        // append the database connection string and save
        entityConnection = entityConnection + "\"" + connectionString + "\"";
        var targetType = typeof (TContext);
        var ctx = Activator.CreateInstance(targetType, entityConnection);
        _context = (TContext) ctx;
    }

    public IQueryable<TEntity> Fetch<TEntity>() where TEntity : EntityObject
    {
        return GetObjectSet<TEntity>();
    }

    public IEnumerable<TEntity> GetAll<TEntity>() where TEntity : EntityObject
    {

        return GetObjectSet<TEntity>().AsEnumerable();
    }

    public IEnumerable<TEntity> Find<TEntity>(Func<TEntity, bool> predicate) where TEntity : EntityObject
    {
        return GetObjectSet<TEntity>().Where(predicate);
    }

    public TEntity GetSingle<TEntity>(Func<TEntity, bool> predicate) where TEntity : EntityObject
    {
        return GetObjectSet<TEntity>().Single(predicate);
    }

    public TEntity GetFirst<TEntity>(Func<TEntity, bool> predicate) where TEntity : EntityObject
    {
        return GetObjectSet<TEntity>().First(predicate);
    }

    public IEnumerable<TEntity> GetLookup<TEntity>() where TEntity : EntityObject
    {
        return GetObjectSet<TEntity>().ToList();
    }

    public void Add<TEntity>(TEntity entity) where TEntity : EntityObject
    {
        if (entity == null)
            throw new ArgumentException("Cannot add a null entity");

        GetObjectSet<TEntity>().AddObject(entity);
    }

    public void Delete<TEntity>(TEntity entity) where TEntity : EntityObject
    {
        if (entity == null)
            throw new ArgumentException("Cannot delete a null entity");

        GetObjectSet<TEntity>().DeleteObject(entity);
    }

    public void Attach<TEntity>(TEntity entity) where TEntity : EntityObject
    {
        if (entity == null)
            throw new ArgumentException("Cannot attach a null entity");

        GetObjectSet<TEntity>().Attach(entity);
    }

    public void SaveChanges()
    {
        SaveChanges(SaveOptions.None);
    }

    public void SaveChanges(SaveOptions options)
    {
        _context.SaveChanges(options);
    }

    public void Refresh<TEntity>(TEntity entity) where TEntity : EntityObject
    {
        _context.Refresh(RefreshMode.StoreWins, entity);
    }

    public void Refresh<TEntity>(IEnumerable<TEntity> entities) where TEntity : EntityObject
    {
        _context.Refresh(RefreshMode.StoreWins, entities);
    }

    #region IDisposable implementation
    private bool disposedValue;
    protected void Dispose(bool disposing)
    {
        if (!this.disposedValue)
        {
            if (disposing)
            {
                // dispose managed state here if required
            }
            // dispose unmanaged objects and set large fields to null
        }
        this.disposedValue = true;
    }

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }
    #endregion
}

A lot of code to be sure, but you only need one of these. After that, whenever you create a new EDMX, you can create a Repository that inherits from this base repository.

Let’s look at using it for the same AdventureWorks repository I used last time:

An Adventure Works Entity Model

Here’s how you might implement a repository for this data model:

public class AdventureWorksRepository : DataRepository
{
    public AdventureWorksRepository(string connectionString) : base(connectionString, "AdventureWorksEntities") { }
}

Yep, seriously. That’s it. Now you have access to all your common CRUD operations (as well as Linq queries) and can do things like this:

var repository = new AdventureWorksRepository(MyConnectionString);

// return all states and provinces
var states = repository.GetAll<StateProvince>();

// get states and provinces with a three letter code
var threeLetterStates = repository.Fetch<StateProvince>()
                                  .Where(s => s.StateProvinceCode.Length == 3)

// get a customer
var cust = repository.GetSingle<Customer>(c => c.CustomerID == 1);

// delete that customer
repository.Delete(cust);

// get a contact
var contact = repository.GetSingle<Contact>(c => c.ContactID == 1);

// edit some properties
contact.Title = "Mr";
contact.Phone = "61 411 111 111";

// save all the changes (this will save the customer deletion and the updated contact)
repository.SaveChanges();

So just by inheriting a base repository class, you can get some really powerful behaviour which is specific to your data model.

I’d be interested to hear your thoughts on this technique, particularly if you try it in your own project.

Just a quick post to let you know I’ll be presenting my “Building Mobile Websites with ASP.NET MVC 3 and 4″ talk at the Qld MSDN User Group meeting on Tuesday the 21st.

Previous versions of this talk have focused mainly on MVC 3 with a nod towards MVC 4. Now that the ASP.Net team have officially launched the beta of ASP.NET MVC 4, I’ll be shifting the focus to the new version.  Out with the old and in with the new!

If you saw the version of this talk I gave at DDD Brisbane last year, don’t be scared off – it’s gone through many, many iterations since then based on the feedback I’ve received.

So if you’re in Brisbane, I’d love for you to come along.  Just RSVP on EventBrite and I’ll see you there!

I’ve stumbled across a few blog posts lately that talk about why everyone should use one technology over another, or why someone is leaving a particular language for another. Obviously there’s no shortage of evangelical blog posts pushing the merits of one technology and lamenting the poor state of whatever-you-plebs-use.  But this latest spate got me thinking.

Most (good) developers talk about using the most appropriate technology for the job.  At its most basic level that means choosing Objective-C for a resource-hungry iPhone app, or writing your latest facebook-killer application for the web rather than the desktop.  That stuff’s obvious.  The more idealist polyglot programmers will take it further and push Ruby on Rails for web apps with a small budget, or they’ll suggest using RavenDB and deploying to AWS because all you need to do is store and retrieve documents across the web. If you’re in a Windows environment with a team running Scrum, choose TFS, C#, and SQL Server.

So “Horses for Courses” right?

The aim is valid and noble, and it’s certainly one I strive for.  But one thing frequently gets overlooked, and that’s the people on the team (or to stretch the metaphor – the jockeys).

If you have a team of programmers who are very used to writing software using certain technologies, think very carefully about advising them to move to something else. I’m not saying don’t do it (in some cases you really should), but there comes a point where the benefits to be gained by using language X on platform Y with source control Z just aren’t worth the trouble.

Unfortunately, most programmers write code in one way. They use one language, they know one data storage mechanism, and they’ve only ever written applications for one environment.  Maybe in a past life they tried out some other language, and maybe they dabble in HTML occasionally, but they’re only experts at one thing.

You, on the other hand, might look at a set of requirements and decide a NoSQL data store running behind RoR is the “best” solution for this project. Similarly, you recommend using git as the “best” source control system to use. Great. Unless you’re the only one who knows this stuff – then you’re dreaming.  If you have a team of C# developers, you’d want to have a pretty good reason for suggesting they program in a different language. If every other project they’re working on uses TFS, learning git is going to introduce a lot of overhead (initially).  Sometimes, the current way of doing things is the “best” way, even if the idealist in you disagrees.

Now, that’s not to say it’s never a good idea to force a shift within a team.  Consider a team of VB 6 developers who, for the last 15 years, have been dutifully writing VB windows applications with an Access back-end. At what point do you tell them it’s time to move on? (Ideally it would have been at least 5 years ago, but that’s clearly not an option). Assuming you don’t outsource or “refresh” the team, you should strongly suggest they change, but acknowledge that the extra effort they’ll have to put in will increase the work. Also be aware that you’re unlikely to get a quality solution from them if they don’t yet know what they’re doing.

My point is, when choosing the right technology for the job, consider everything, and that includes the skillset of the developers.

With that in mind, blog posts encouraging everybody to stop using .Net because it sucks, or telling them they should never use pure HTML and JS for business apps are just ridiculous. Yes, you might have had an overnight change of heart and now realise language X is the worst thing in the world, but you’re thinking about the specific situations you’ve been in, and developers with specific skills (usually just the individual author). If your whole team can just up and move to Ruby, then fantastic! Say hi to the rainbow coloured unicorns for me!

It’s always good to encourage teams to learn new technologies. It’s occasionally good to force a team to move on, but sometimes the “best” way isn’t the “ideal” way.

How to be a Good TFS Master

I recently gave a talk at the Qld ALM User Group on the topic of “How to be a good TFS Master”.

Hopefully those who turned up got some great tips on how to use TFS more fully, but the main points I hoped people left with were:

Most people only use about 20-30% of the capabilities of TFS

In our experience, the majority of companies using TFS are using it for source control only.  SSW helps teams get closer to using 80 or 90% of TFS where the real advantages can be felt. There are some fairly significant infrastructure costs associated with getting to 100%, and we find most organisations don’t want to go that far.

TFS is much more than source control

In fact, if you’re using TFS purely for source control, you’re doing it wrong! You might even be better off using Git or Mercurial.  The best option (of course) is to start using TFS more fully to help you get the best out of your team.

TFS supports your Scrum process beautifully

TFS has some awesome capabilities that allow you to manage and support your entire scrum process. The integration story is compelling; allowing you to tie code changes directly to user stories, produce genuinely useful reports for your managers, and enforce your policies and coding standards allowing you to tick items off your Definition of Done without any effort.

For more information or some reminders of what I spoke about, have a look at the slides on Slideshare - http://www.slideshare.net/damovisa/how-to-be-a-good-tfs-master

I’m working with a client at the moment on a system using legacy database with (wait for it) about 50 lookup tables in their database.  We’re using Entity Framework to access the database, so it’s fairly easy to get the data out of these lookup tables.

However, I really don’t want to write 50 methods to return lists for each of these objects.  Thankfully, the solution is relatively simple – write a generic method to return the appropriate data.

Implementing this wasn’t quite as easy as I thought, but I got there after a bit of experimentation and, I’ll be honest, a fair bit of googling.

To demonstrate, let’s look at an Entity Model with a subset of the AdventureWorks database.

An Adventure Works Entity Model

In particular, look at the red outlined objects.  These are likely to be referred to frequently throughout the application as simple lookup tables.

We want to write a single generic method that will return an IEnumerable of these objects so we can use them quite simply as lookup tables.

Here’s what I ended up with:

AdventureWorksEntities adventureWorksEntities = new AdventureWorksEntities();
 
public IEnumerable<T> GetLookup<T>() where T : System.Data.Objects.DataClasses.EntityObject
{
    try
    {
        var key = typeof(T).Name;
        // 1. we need the container for the conceptual model
        var container = adventureWorksEntities.MetadataWorkspace.GetEntityContainer(
            adventureWorksEntities.DefaultContainerName, System.Data.Metadata.Edm.DataSpace.CSpace);
        // 2. we need the name given to the element set in that conceptual model
        var name = container.BaseEntitySets.Where((s) => s.ElementType.Name.Equals(key)).FirstOrDefault().Name;
        // 3. finally, we can create a basic query for this set
        var query = adventureWorksEntities.CreateQuery<T>("[" + name + "]");
 
        return query.ToList();
    }
    catch (System.Data.EntityException ex)
    {
        throw new ArgumentException("Invalid Entity Type supplied for Lookup", ex);
    }
}

Now we can use the following code to return a set of all items of the appropriate type:

AdventureWorksRepository repository = new AdventureWorksRepository();
var states = repository.GetLookup<StateProvince>();
var addressTypes = repository.GetLookup<AddressType>();
var territories = repository.GetLookup<SalesTerritory>();

This has saved me countless hours of writing boring plumbing code.

Hopefully, some of you are already looking at this thinking, “couldn’t I take this a lot further and provide a set of generic data access methods for everything?”. The answer of course is yes.  I haven’t gone quite that far yet, but I wouldn’t be surprised if it was down the track.

Recently I gave a presentation at Ignite Brisbane where I spoke about “The Rise of Participative Software”.

You may remember me briefly talking about this topic in an earlier post, as it’s something that I’m fairly excited about.  The general idea is that most software just does exactly what the user asks.  You give it some explicit input, it gives you some output.  Participative Software is my name for software that makes suggestions and “participates” without explicit input.

Watch the video for more details.

The five minute time limit meant that I didn’t quite get my point across as well as I’d hoped.  I’d like to present the topic over 20 or 30 minutes so I can really drill down on the subject and include a bit more of a call-to-action.

As always, feedback is more than welcome – especially if you’d like to hear a 30min version!

Yep, jQuery 1.4 has been released.

Here’s a great post from nettuts outlining some key differences and new features.

I don’t really have much to add on this, but just a few thoughts:

1. Speed improvements are good and all, but when you can get ten times better javascript performance by changing browsers, nearly doubling the speed of your .css() method not the most important thing. Still, I can’t expect the jQuery team to be able to retire browsers for people I guess…
2. A lot of changes seem to deal with allowing functions to be passed into methods.  Being a .Net 3.5 guy, I’m love this anonymous delegate stuff, so it’s good to see!

Yeah, that’s all the comments I have right now. Told you I didn’t have much to add!

It all started when I decided that I’d rewrite a partially-aborted PHP web app of mine in .Net. The PHP version was relatively functional, but PHP is not my strongest skill, so updating and improving it was hard. Combined with a lack of good quality free time, it meant that I didn’t have the inclination to update it much.

Much of the design work is already done. The database schema is solid and it isn’t trivial – it took me a number of iterations to get right. The UI flow has been decided, and at this point, I’m happy to reuse most of the layout, css and images.

At Tech.Ed this year, I heard a lot of great things about ASP.NET MVC. The Hands-On-Lab I did gave me just enough of it to get me interested, so when I decided I was going to rewrite this thing in .Net, MVC seemed like the way to go.

So I’m now attempting to learn how it all works, and it’s going really well. The secret? The NerdDinner tutorial courtesy of Rob Conery, Scott Guthrie, Scott Hanselman, and Phil Haack (actually I get the impression that Scott Guthrie wrote the tutorial, but the originating book is authored by all of them).

Seriously, if you’re looking at playing with ASP.NET MVC, run through this tutorial from start to finish. I guarantee by the end of it you’ll be all over the basics, and loving the way ASP.NET MVC is put together.

I’m looking forward to getting into some real development with this project.