Entity Framework, Csla, and large scale enterprise applications

Entity Framework, Csla, and large scale enterprise applications

Old forum URL: forums.lhotka.net/forums/t/6914.aspx


CyclingFoodmanPA posted on Thursday, May 07, 2009

Ok, I am getting pretty psyched reading about the Entity Framework and using the book "Programming Entity Framework" by Julia Lerman.  I am finishing up Chapter 3 and went through the examples pretty well.  I started creating a project with a small DB and going through the modifications to the model that she requested.  Here is where I am going:

The changes are not to bad for a small application, say under 20 tables.  When you get to a large application, say 180+ tables, there seems to be a lot to do (pluralization of Navigation Properties, pluralization of the Entity Set Names, etc.) and all this has to be done in a systematic, organized method, otherwise if you miss something and gen your code, you will have to go back and redo some stuff.

I went and created a sample of this on my own with a pricing table and followed the same steps for the example in the book.  However, I am getting some strange error now as follows:

System.Data.MetadataException was unhandled
  Message="Schema specified is not valid. Errors: \r\nThe EntityType 'BelAirPricing.CopyOfSpotLocation' that the NavigationProperty 'PLATTSProducts' is declared on is not the same type 'BelAirPricing.SpotLocation' referred by the end 'SpotLocation' of the RelationshipType 'BelAirPricingModel.FK_SpotLocation_PLATTSProduct' that this NavigationProperty represents."
  Source="System.Data.Entity"
  StackTrace:
       at System.Data.Metadata.Edm.ObjectItemCollection.LoadAssemblyFromCache(ObjectItemCollection objectItemCollection, Assembly assembly, Boolean loadReferencedAssemblies)
       at System.Data.Metadata.Edm.ObjectItemCollection.LoadAssemblyForType(Type type)
       at System.Data.Metadata.Edm.MetadataWorkspace.LoadAssemblyForType(Type type, Assembly callingAssembly)
       at System.Data.Objects.ObjectContext.CreateQuery[T](String queryString, ObjectParameter[] parameters)
       at BelAirPricing.BelAirPricingEntities.get_NYMEXHistories() in D:\Visual Studio 2008\Entity Framework\Books\Programming Entity Framework\Chapter03\BelAirPricing\BelAirPricing.Designer.cs:line 98
       at BelAirPricing.Program.QueryNYMEXPricing() in D:\Visual Studio 2008\Entity Framework\Books\Programming Entity Framework\Chapter03\BelAirPricing\Program.cs:line 19
       at BelAirPricing.Program.Main(String[] args) in D:\Visual Studio 2008\Entity Framework\Books\Programming Entity Framework\Chapter03\BelAirPricing\Program.cs:line 12
       at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
       at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
       at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
       at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()
  InnerException:

and this is a small (13 table) db that I am practicing on before I dig into my big enterprise application.  So, my question is, is anyone out there developing a large scale enterprise application with the EF and if so, how are things going.  Are there any major bottlenecks that you have had to overcome, how did you do it, etc?  I am the sole developer at my organization so some feedback and "helpfull hints" from other developers would be great!

Thanks in advance for your help and keep on developin'

CyclingFoodmanPA

 

 

 

 

dlambert replied on Thursday, May 07, 2009

I haven't done large-scale EF yet, so take this with a grain of salt.  My impressions when playing with it, though, were pretty similar to yours:  As long as your data model and application (1) is internally consistent across the whole of the application, and (2) agrees with the "Grand Unified Theory of EF", you're golden.  My experience was that as soon as you depart from that mainline, however, stuff starts to get a little bumpy.

If I were going to dive into this in a big way, I'd look for some places to partition my data model so that I could produce a number of EF models of a manageable size.  That's not always going to be easy, but if you can't do that, I'd be very worried about a localized problem rendering the entire data model unusable. 

I had a similar experience a few years ago w/ Hibernate -- there was no such thing as an isolated problem.  I chalk this up in part to my ignorance w/ Hibernate, but also to the tactic of trying to create one big model to rule them all.

Copyright (c) Marimer LLC