Should I create a ADO.NET Entity Data Model for each table, or one for my entire database?

Question

Are you supposed to use one ADO.NET Entity Data Model for each table? Or one for your entire database where relationships are also routed, etc...

Answer 1

Do it for the entire database. If you make a data model for every table you will not have the benefit of navigating the relationships.

If you're using checkout/merge source control like Subversion, be aware that the designer munges the XML to the extent that Subversion struggles to merge it. In this case you usually have to regenerate the entire model every time or merge by hand.

Answer 2

I use an Entity Data Model for related tables. Depending on the size of your database I would only create one model if there was less than about 20 or 25 tables. It is a bit expensive to create individual models for every table because each model has a EntityConnection object to be created.

I find I can maintain the models fairly well if I have between 5 and 15 tables. My main deciding factor is functionality. I build engineering applications so for example I have about 6 tables of structural steel components. They are all in one model. They share common engineering attributes so it's easier to reuse code that is specific to manipulating those attributes.

This means that I can instantiate the model, create the objects, manipulate/organize those objects within a common code file. Any changes that need to be propogated back to the database can be done quite efficiently.

The bottom line is determinig your need and frequency of use for the underlying objects. If your going to be constantly updating one or two tables then it doesn't make sense to have 30 other non-related tables inside that model. In this scenario where a small number of tables are being used frequently, it might make sense to create collections of these objects, manipulate the collections and update the database at appropriate times.

Memory maipulation is much cheaper to perform then disk I/O. This is just my take on the framework and by no means am I an expert at it.