Channel 9 published a
very interesting video about Microsoft's O/R Mapping tool that will be included in a future version of ADO.NET. It is actually a remake of a video that was published a couple of months, also in Channel 9, only to be shutted down soon after.
As almost every .NET developer does, I use ADO.NET every day, and have been a fan from
the first hour.
But as an architect -in a limited sense I must add- I have to deal a lot with both theoretical and empirical aspects of multi-tier development, so I have been looking for the silver bullet for the Data Access Layer for years.
Pablo Castro, Technnical Lead of ADO.NET (and a native from Buenos Aires!) was very nice answering the comments
I posted to Channel 9. I will reproduce my own writting here, but you can read his very interesting answer
directly on the site.
As I mentioned before, one of my great concerns is how team development will look like with the Entity Framework. I took some time to detail my thoughts:
First, many real life projects are partitioned in modules, so their data layers are partitioned likewise.
Often, there are sets of tables that are used exclusively in each module, and a set of tables that are common to all. Yet, there are some tables that are reused in more than one application (typical examples are security, navigation, etc).
Besides, building a useful data layer is not done in one step nor does it take a single day. It is more often an evolutionary and error-prone process in which a programmer “imports” objects from the database each time he/she realizes they are mentioned in the specification.
During this process, errors that affect maintainability (duplications, improper use of naming standards, etc.) are very usual.
So, here is a short list of features that I would like to see in the Entity Framework (some are actually hard requirements). Of course I ignore if any of these are already included:
- Partitioning of the conceptual model in multiple files and assemblies.
- Referencing and extending (entity inheritance) between entities defined in separate files and assemblies.
- Creating reusable “libraries” containing entities and mappings that can be reused by different modules or different applications.
- "Incremental" reverse engineering of databases (I think this one is already in the graphical design tool).
- Support for basic refactorings (unification, replacement, renaming, etc).
- Very readable and maintainable XML (it should be easy to merge two files with a source code comparison tool).
- Efficient and easy serialization of entities and entity sets outside the database.
- Separation of the conceptual model from the persistence logic (take a look at what Steve Lasker does with typed datasets).
- A migration tool for typed datasets XSDs.
- A degree of resiliency to some schema changes.
If you can answer any of my doubts, I will be grateful. My boss is pressing me to evaluate O/RM products, and I am telling him to way for your framework everyday :).
All in all, I am very enthusiastic about this new piece of technology. I think it could make my life and the life of many other developers a lot easier and also more interesting!
