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 resued in more than on 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
Good point. We do have some modularization mechanisms (more details inline with your questions), but I think you put it in interesting terms, that is a good way of thinking about how metadata is organized and deployed.
I have included some comments below on the specifics. Of course, as in any software product in development, things are subject to change
- 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.
1. Yes, you can partition the model in multiple files
2. Yes, you should be able to do this (although some glitch here or there may complicate things)
3. Yep (you may need to deploy a library + metadata)
4. We currently don't have plans for automated incremental reverse engineering. Currently we do "one shot" reverse engineer and then you can maintain the resulting model by hand. Is that something you could live with for the initial release?
5. While you can re-factor the model (and we'll propagate the changes to your object model in CLR classes), we won't automatically propagate the changes through the mapping, at least not this time...
6. "very readable"...well, it's XML, so you can read it
; in my experience, in most cases you can design "good looking" XML that works well for small/medium data-sets, but as the amount of data you need to represet grows, things get tricky regardless of the
actual schema; there are other aspects that need to be considered and balanced, such as the evolution of the schema across versions of the framework and making sure there are no ambiguities. That said, we are looking at making sure the XML is relatively clean.
7. Our plan is to have a mechanism to enable shipping of entities across tiers and allow for the system state to be reconstructed later on, however, that doesn't not include taking care fo serialization itself. We assume that you'd use any of the already-existing
8. Following the typed-table pattern, what you're saying is that you'd like the option to have the "typed ObjectContext" in one assembly and the domain classes in another one, is that right?
9. We don't currently have one planned, but hey, we do have a developer community that might be interested in contributing a few of these nice tools
10. The mapping infrastructure does provide a good degree of isolation from schema changes for the applications built on top of a conceptual model. This requires that you manually update the mappings to map to the new schema, but other than the map everything
else should go untouched (of course, there are certain types of changes that we cannot compensate for).
Hope this helps clarify some of the issues. This provided me with good perspectives on certain problems, thanks for the write up.