From DomainObjects to the Entity Framework
Brought to you by:
rbeauchamp
Menu
▾
▴
I have been diving deep into the Entity Framework design, interfaces and implementation, to understand how I can create a migration path from DomainObjects to the Entity Framework.
Wow, Microsoft has been doing a huge amount of work over the past few years! Lots of classes, API, documentation and community blogging and involvement. The Entity Framework seems to now have most of the features of DomainObjects. ;-)
At the heart of the framework is the metadata, similar to the DomainObjects repository.xml file. Seems you have to use Microsoft's schema and XML even when working with 'plain old CLR objects' (POCO). So after a large amount of work under a new branch (https://domainobjects.svn.sourceforge.net/svnroot/domainobjects/branches/DomainObjects4) in which I removed the dependencies on the DomainObjects base classes (to support POCO) and removed dependencies on the DomainObjects Query<T> class among many other changes, I am going to stop modifying this branch and take a new direction: create a new branch, DomainObjectsToEF, where I will replace the repository.xml file with the Microsoft Entity Framework (EF) equivalent. This will provide at least two benefits:
1. An ability to leverage the EF visual conceptual modeling and mapping tools.
2. A migration path from DomainObjects to EF.
The new branch is available at https://domainobjects.svn.sourceforge.net/svnroot/domainobjects/branches/DomainObjectsToEF if you'd like to follow the progress or join the effort.
So are you saying that the DomainObjects roadmap is to migrate to EF?
Do you think that we will be able to move all our DataProviders to EF?
I had the idea that EF was just SQL Server friendly…
> So are you saying that the
> DomainObjects roadmap is to migrate to
> EF?
Yes, as long as we can retain the features and performance of DomainObjects. This seems like an appropriate path given all the support from Microsoft: developers, code, API documentation, tutorials, community involvement, etc. I see us leveraging the EF infrastructure as much as possible, while adding features that EF does not support.
> Do you think that we will be able to
> move all our DataProviders to EF? I
> had the idea that EF was just SQL
> Server friendly…
I was just looking at a sample , based upon this . Seems like a good start. Currently only the SQL and Oracle providers are being maintained in DomainObjects, (by you and me respectively), so I don't think it should be too hard given the above code samples.
: http://code.msdn.microsoft.com/EFOracleProvider
: http://code.msdn.microsoft.com/EFSampleProvider
Richard
We've been using Domain objects since the beggining (OJB 0.?) and now our applications (brazilian government) count millions of lines of code. Thank you !
Nowadays we are using Domain Objects 1.5 and we are planning a migration. Any progress on this branch (Domain Objects to EF) ? We are very interested on using POCOs and EF mapping tools.
Best regards,