This project is read-only.

Advance notice: Significant change to approach on Code First

Sep 12, 2012 at 12:21 PM
Edited Sep 12, 2012 at 12:22 PM

From the next release we will be changing the way that Naked Objects interacts with the Entity Framework Code First capability. This change will not impact your domain model code, but will impact the way the Run class is configured for Code First operation.

The motivation for this change is to align Naked Objects more closely with the conventional approach, for example as described in Julie Lerman's book ('Programming Entity Framework: Code First') and numerous on-line blogs and tutorials.  

The biggest change is that you will need to create a DbContext (where, to date, Naked Objects has created the DbContext for you transparently at run-time).  You will do this in exactly the same way as for a conventional Code First project.  For example:

   public class BreakAwayContext : DbContext {
        public BreakAwayContext(string name) : base(name) {}
        public BreakAwayContext() {}
        public DbSet<Destination> Destinations { get; set; }
        public DbSet<Lodging> Lodgings { get; set; }

(An actual  example from Julie's book). Note, that as with conventional CodeFirst, it is not necessary to specify the DbSet for each domain type  -  as long as the domain types can all be accessed by 'walking the graph' from one or more root nodes.)

Although this change will make the 'five minute demo' of Naked Objects very slightly less impressive (because there is this one more class to write), it has huge advantages in terms of the ease with which you can then specify configuration details on the DbContext.  

The only other change required is that you will need to tell the Run class how to create this DbContext (or DbContexts, if you want to create multiple databases from your model(s)).  This will be done through the EntityPersistorInstaller, via a new method AddCodeFirstDbContextConstructor:

protected override IObjectPersistorInstaller Persistor {
	get {
		var p = new EntityPersistorInstaller();
		p.AddCodeFirstDbContextConstructor(() => new BreakAwayContext());
		return p;

The reason why this method requires a delegate (rather than simply an instance of the DbContext class) is so that you can optionally also pass in various initialisation parameters, such as the database name to be used  -  again in the same way as used in conventional Code First development.

In summary, this will be a breaking change, but a small one  - and we hope that the big advantage will be recognised by all it impacts.

May 8, 2013 at 6:00 AM
Dear Richard,
                   It looks like the sample you have in NO5.4 is not using the new EF code first convention for setting the database context. Will you be updating the sample?
May 8, 2013 at 9:34 AM
Edited May 8, 2013 at 9:35 AM
The sample app (I assume you are referring to the AdventureWorks demo?) was written using .edmx - the only option at the time we wrote it. We may convert it to Code First at some point, but it is not high priority. It is quite a large app and converting from Model First to Code First is quite tedious - my experience with third party auto-conversion tools for this has not been positive so far.

P.S. If anyone else wants to take this on let us know.