How is Entity Programming changing the way we think about databases?

Question

I am wondering how the shift from relational, table-based design to object-oriented, entity-based design is affecting the mindset of developers writing the next wave of applications.

Given the nature of the debate swirling around the Entity Framework and Linq to SQL, is it premature to be thinking about entity-driven design?

Are we bringing up a new generation of developers who won't understand the basic principles of relational database design and development, because they will be shielded from them by tools like the Entity Framework? Is the Entity Framework really smart enough to make these kinds of design decisions for them?

Answer 1

Hmmm, difficult question to answer imho.

I don't think that tools like 'the entity framework' will lead to bringing up a generation of developers that do not understand the principles of relational database design. First and foremost, object oriented design is already a long time around, and people have been searching for solutions to bridge the gap between OO and RDBMS'es for ages.

I don't see 'entity driven design' as you call it (I'd rather call it domain driven design), replace relational DB design. In fact, for me those 2 things will continue to live next to each other, as both technologies are -IMHO- the best solution for the problem they're trying to solve: - OO is the perfect way to model data + behaviour - the relational model is the perfect way to efficiently store data and run queries on it.

If you want to be successfull in creating an application in a domain driven fashion (using an O/R mapper like NHibernate or the entity framework), it is still necessary that you - the developer - have a basic understanding and knowledge of how the relational model works. In fact, you're still talking to a relational database, albeit through the O/R mapper. If you want have a well performing application, you'll have to know that a relational database is set based, for instance; that it is not a good idea to perform a SELECT n + 1 query, etc...

In fact, I'm using an O/R mapper (NHibernate) for one year (professionaly), and I've been playing with it for a few years, but I still prefer to create my relational data model by hand. I do not generate my DB model through my O/R mapper via the classes I've written, since I'd like to be in control.

So short answer: I think it will still be required that a developer understands the relational model if he wants to be successfull using an O/R tool.

Answer 2

Good question.

First, I don't think we aren't quite there yet. Entity Framework and it's peers are some good early steps into what could be called entity-driven design. But we are surely far from taking the technology for granted when designing our software solutions.

As for your second point.

Are we bringing up a new generation of developers who won't understand the basic principles of relational database design and development, because they will be shielded from them by tools like the Entity Framework?

Would it be such a bad thing to encapsulate one of the most painful parts of current software development away from the day to day developer? I see it in the very same light as memory management when higher order languages started luring developers away from c++. Does it mean that you can forget about memory management? No, not at all, but you don't have to focus on it at nearly the level of intensity as before. Leaving more brain cycles to focus on your software's business problems. If it is possible, I look forward to the day when I can do the same thing with my persistence model.