(This post is a followup to a post on EF vs NHibernate )
As discussed in the post referenced above, my team's task was was a rework of a previous project we were all somewhat new to, and we were dealing with a database that could not be substantially changed. It's not an ideal situation, but a pretty common one in brownfield projects. When we had experimented with Entity Framework on this project, we just pulled in the tables through to the model and started working. (not for long, as it happened) When we decided to instead go with NHibernate, we decided to map by hand.
Starting out, we thought the initial hand-mapping would be a lot of extra time over the EF method of auto-building classes-time we were willing to put in since at least it would be straightforward compared to the problems we'd had with Entity Framework. We had a fair number of classes with pretty complex relationships, so hand-mapping was going to take a bit of time. Anyway, we dove in and started mapping. As we started mapping out our relationships, we ran across some oddities-WHY were things set up as they were? We started questioning why certain relationships were in place, and why they were set up as they were (in some cases, there were extraneous foreign keys and duplication). Other tables didn't seem to be contributing anything at all except complexity. After seeing these things, we took a closer look at how the tables were actually used, and found that some things were not mapped well based on actual usage. This started team discussion on what the objects were creating really *were*, if the existing naming made any sense at all, then followed and spirited talk on how we should really set up our classes, and what we could do about it given our constraints. To save some time with all of this analysis, one of the team members also ended up writing some scripts to help do a rough initial pull of simple properties (string, dates, etc) through the mapping files to the classes-they didn't merit the same level of study at this time, and helped us finish the sprint on time.
The result of studying the tables was a compromise of tweaking some table relationships in backwards-compatible ways, renaming classes, (if not tables, since that was not available to us) creating views on top of existing tables, and in some places, simply we made note of some inconsistencies that simply could not be dealt with on the current project. In the end, we had a much deeper, nuanced understanding of the current work, and a much better idea of how we would deal with it going forward then we would have had otherwise. Best of all, we gained that understanding right at the beginning of the project when it could do the most good. To be fair, the understanding we gained wasn't a result of NHibernate itself, it was more an artifact of the way we ended up working-essentially, we ended up going through a rough exercise in building a model for ourselves that we would not have done otherwise. But had we succeeded with Entity Framework, I don't know when or if we ever would have understood the project in that way, and I'm certain that that lack of knowledge would have burned us.
12-29-2008 8:15 PM