I have several times commented that the thing I would most like to see added to Entity Framework would be automatic management of database schema changes while preserving data.  Somehow I managed to miss the  Entity Designer Database Generation Power Pack, which does just that. I have used it with Naked Objects MVC and it allowed me to evolve my model, preserving the data that I had entered.

The power pack is clearly experimental, and suffers from a number of limitations. For example, it copes well with additions of new entities , new properties on existing entities, and changes to the attributes (e.g. string length) on existing properties.  However, it does not cope with renaming, or deletion, of existing entities or properties.  For that you will need to revert to SQL queries.

But it is to be hoped that Microsoft will address these limitations in the next release  -  and that the power pack will eventually be included within the Visual Studio release.

Also, at present this capability is designed to work with Entity Framework in ‘Model first’ mode, but there is no reason (that I can see) why this shouldn’t in future be compatible with Code first.  In the interim, finding this power pack has shifted my own focus back from Code first to Model first.

I also got to thinking that the combination of Naked Objects MVC with this Entity Designer Database Generation Power Pack gives us a real competitor to Rails as a tool to support iterativer development of data-oriented web applications.  To be sure the Rails capabilities for data migration go further than this, but then Naked Objects MVC has many advantages over Rails in other ways  -  not least because it uses generic views rather than code-generated scaffold views  – so you end up with far less code to maintain.

Richard

We’ve experimented and discovered that deploying a NakedObjects MVC application on Microsoft Azure is very straightforward.  These are the high level steps we went through -

Prerequisites

- A working NakedObjects MVC application with database
- Microsoft Azure developer account
- Microsoft Azure SDK installed on your PC

First create a new SQL Azure server and database. Connect to it via Sql Server Management Studio or VS2010. We populated the schema from our local database by using the .edmx.sql file you get when when you ‘Generate Database from Model’ on the .edmx file, then we populated the data with some generate scripts from our local database.  (To connect see here)

Next stage was to create a new ‘Cloud’ project in VS2010 with a single MVC2 Role, using the ‘Add new project’ templates. Then you can either copy across all your controllers, views etc from your existing MVC project to the new MVC web role project or alternatively copy across the Web.Role file and merge the config into your existing project. In the second case update the Web Service to point to your existing project and delete the unused Web Role template.

Now update the connection string in the web.config file to point to the SQL Azure database (see here) and you should be able to run the application locally in the Azure simulation environment against the Sql Azure database.

Once that works ‘Publish’ the service and the on the Azure site create a new service and deploy. Once the service is ‘Ready’ you should be able to navigate to the URL and see your application running in the cloud.

Working ‘Code First’ A couple of weeks ago, Microsoft  released it’s fourth version of the Entity Framework Feature CTP (http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=4e094902-aeff-4ee2-a12d-5881d4b0dd3e), which enables ‘Code First’ development.

A couple of weeks ago, Microsoft  released it’s fourth version of the Entity Framework Feature CTP, and we have just released a new version of Naked Objects MVC to work with this ‘CTP4′.

This series of Feature CTPs is concerned with what Microsoft calls ‘Code First’ development (using Entity Framework).  What they mean by that is that you should be able to write your domain objects as pure POCOs, and have them persisted on a relational database, without having to write any additional code or even configuration.  This is an impressive idea, but the earlier versions of Code First (CTPs 1,2,3)  had a number of severe limitations that meant that Code First was not really suitable for prime time development. With CTP4 those limitations have been addressed and it appears to us that Code First is now a viable idea for mainstream development.

You can read about the various specific improvements made to Code First on the ADO.NET team blog and elsewhere.

Philosophically, Code First and Naked Objects follow the same philosophy:  use ‘conventions’ first, annotation (attributes) second, and explicit coding 0r configuration third.  But its more than just a philosophical match.

The combination of the latest incarnation of Code First and Naked Objects MVC  is strongly synergistic.  Code First basically looks after everything underneath the domain objects and Naked Objects looks after everything on top of them.  The net result is that you can build a complete web application for a complex domain model, solely by writing domain objects as pure POCOs.

Richard

The Entity Framework (EF) approach to concurrency is to mark one or more fields as ‘ConcurrencyMode=Fixed’. This can be done either directly in the edmx file or via the Entity Data Model Designer. The EF will then use the original value of the field as a condition on any update. If the value has changed the update will fail and a concurrency exception will be thrown.

This works well for a long running context and so we been happy to use it for thick-client implementations of Naked Objects. However the MVC implementation uses a context that only survives for the duration of the web transaction. The EF concurrency check will then only check for changes during that transaction – this is of some value but it doesn’t catch the situation where an object is opened for edit (in one transaction) changes are made and then submitted (in another transaction).

As a slight aside here we need to be aware of how Naked Objects MVC handles the persistence of an object from one transaction to the next. Naked Objects passes an identity token (in the URL) which is then used to repopulate objects from the data store. These are then used to make any changes or run any actions and then save changes to the store. This has the advantages that it is completely stateless – everything is in the Http Request – and cleanly decoupled from the object store implementation. It does though have the disadvantage of an additional object store query.

With EF an alternative would be to serialize all or some of the object state, recreate the entity and attach to the context. This is an option for the future but there’s quite a few hoops to jump through to get this working, especially in an object store independent way and within the constraints of the existing Naked Objects architecture. So for the moment simplicity and object store independence win the day.

So back to concurrency, it seems to be possible to set the token in the object and tell EF to accept it. Then when other changes are applied and the object saved the standard EF concurrency checking should kick in. This is obviously a good solution in that it’s a common concurrency mechanism across thick-client and MVC Naked Objects implementations. This would be easiest if we had adopted the reattaching EF mechanism but should be possible with our current object retrieval mechanism. However it once again means coupling ourselves to EF or building a lot of EF specific stuff into our generic object store API.

Finally then the simple approach we adopted is to save the concurrency token as a hidden field on object edits and views. For edit sessions the original value survives the length of the edit (which may involve intermediate posts). Then when the edited object is saved or an action is invoked we check against the current database value (which we’ve populated in the object anyway) and fail concurrency if it’s changed. This is simple, obvious what’s going on if you want to customize the application and fits in cleanly with our existing architecture. The only disadvantage is that we need a way of identifying the concurrency token fortunately Microsoft have provided a new attribute – ConcurrencyCheckAttribute – which we use. As this is also used in EF Code First to mark those properties that are “ConcurrencyMode=Fixed”  this is all that is necessary for Code First development. For Model and Database first the same fields marked “ConcurrencyMode=Fixed”  should also be annotated ‘ConcurrencyCheckRequired’.

Earlier today we released the Evaluation Version of our newest product – Naked Objects MVC – which combines the power of Naked Objects for .NET with ASP.NET MVC. (If you haven’t seen this, visit our website, watch the demo videos and download the free Evaluation Version).    This is a milestone for Naked Objects, for two reasons: it means that we can generate a pure HTML user interface from a domain object model, and it means that we have an interface that is fully customisable.   I also think that this is a milestone for MVC, and here I don’t just mean ASP.NET MVC, I mean the MVC pattern in general. Let me explain why.The ‘naked objects pattern’ was the product of my PhD research, which I undertook at Trinity College, Dublin. In my thesis I was quite critical of the impact that the MVC pattern had made on object-oriented design. Although this was never the intent of the MVC pattern, in practice it had led to people putting too much domain logic in the Controllers, and even the Views – resulting in ‘anaemic model objects’.

The original idea contained in the thesis was that it ought to be possible to create a user interface that was a direct reflection of the Model, without requiring any UI coding at all. A framework that implemented this ‘naked objects pattern’ would probably use Views and Controllers internally, but they would be invisible to the domain model programmer.

When I completed my thesis in 2003 my supervisor faced the usual challenge of trying to find an external examiner who could do it justice. You can imagine my feelings when he decided to invite Trygve Reenskaug – who first proposed the MVC pattern back in 1978. But Tyrgve was very gracious, and in fact I was awarded my PhD before any cross-examination by the panel of examiners (which is quite unusual). At the viva (defense) Trygve also revealed something that did not appear in any of the literature. He said that it was always the intention of his team that Models should have default Views/Controllers, but that they had never realised that idea.

Ever since then, I have had the dream of a framework that would allow you to span both worlds: to have a default View/Controller that would give you a complete user-interface for free (and not just CRUD operations – full object behaviour as well), but then allow you to write your own Views and/or Controllers as you needed. And, preferably, I wanted to realise that dream using someone else’s MVC framework, rather than invent a new one from scratch.

Microsoft’s ASP.NET MVC framework (specifically the second release ‘MVC 2′) proved up to the job. If you look at the Naked Objects MVC implementation you’ll see that we manage with just a single GenericController and only half a dozen generic views. An experienced ASP.NET MVC programmer could probably re-create this from scratch in a few weeks. But, like the proverbial swan (elegant on the surface, but lots of paddling beneath it) this only works because of the phenominal capabilities of the existing Naked Objects for .NET framework underneath.

Richard