Partition of EF Model for large application.

I would say that a very large model will negatively affect performance.   However, too many models are a pain to manage.  One rule to keep in mind is that if you try to update two different models within the same transaction you will have to rely on MSDTC because each context.SaveChanges is one transaction.  So, if you cleanly divide your tables with this in mind, you should be OK.

Sergey Barskiy

Principal Consultant

office: 678.405.0687 | mobile: 404.388.1899

Microsoft Worldwide Partner of the Year | Custom Development Solutions, Technical Innovation

I am getting ready to attack a fairly large project (currently 184 tables, 330 Relationships, etc.) and I am going to take the plunge with Silverlight 3, EF 1.0, Csla 3.7.x or Csla 3.8.x or whichever version is the most stable and current!

I have read that EF models, when they get large (100 tables) have problems.  Don't remember specifically what the problems were, but I remember reading there were problems.  Would it make sense to partition my EF Models in terms of functionality of the tables.  For example, there are some admin tables, some Operations tables (Products, Source, Product Blending, etc.), some Accounting (Billing, Tax Tables, etc.) and numerous other sub systems pertaining to the large system. 

Would it make sense to partition the EF Model into subsystems and keep the business objects (Server and SL) in one .dll (Rocky mentioned earlier that it is good to keep the number of assemblies down and that makes sense based on his reasoning).  Doing this, each EF Model could have anywhere from 20 tables to 50 depending on the sub system.  Any advice, recomendations would be most appreciated.  Yes, I know it is EF v1.0, but I have to start somewhere and I don't want to wait until EF 2.0.  There may be some converting of code when the new version comes out but might as well go for it.

CyclingFoodmanPA

That is what I thought as well.  Context actually has an overload that takes store (underlying) connection, but if connection is already open (which it will be because it was using by another context), constructor will throw an exception “Connection already open”.  I even posted this on the EF forum (http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/01e68e13-04ca-4576-8808-8dd7aca5f273 ), but got no reply.  The only way around it that I am aware of is to rely on MSDTC.

Sergey Barskiy

Principal Consultant

office: 678.405.0687 | mobile: 404.388.1899

Microsoft Worldwide Partner of the Year | Custom Development Solutions, Technical Innovation

sergeyb:

I would say that a very large model will negatively affect performance.   However, too many models are a pain to manage.  One rule to keep in mind is that if you try to update two different models within the same transaction you will have to rely on MSDTC because each context.SaveChanges is one transaction.  So, if you cleanly divide your tables with this in mind, you should be OK.

Is that really true Sergey?

You'd think there would be some way to get EF to use a pre-opened database connection or something, so you could update multiple models against the same database by reusing the same connection?