Working With Large Models In Entity Framework – Part 1

infoblog » Working With Large Models In Entity Framework ??? Part 1

infoblog » Working With Large Models In Entity Framework ??? Part 1 — Mon, 24 Nov 2008 20:21:49 GMT

PingBack from http://blog.a-foton.ru/index.php/2008/11/24/working-with-large-models-in-entity-framework-%e2%80%93-part-1/

re: Working With Large Models In Entity Framework – Part 1

juliel — Tue, 25 Nov 2008 01:51:11 GMT

I'm really looking forward to seeing these and have donloaded them but they are the raw files. One of the points you have made is that using these patterns you can do all of the work in the designer. Any chance of sharing some EDMX files so we don't have to dizzy ourselves looking at the raw xml and moving back and forth from one file to another to mentally put it all together?

thanks

julie

re: Working With Large Models In Entity Framework – Part 1

Erik Wynne Stepp — Tue, 25 Nov 2008 08:06:27 GMT

You state above that "the prescriptive guidance from EF team is to pre-generate views for all EF applications."

If this is the case, then why do you not provide a better integration scenario in Visual Studio?

The steps that you suggest are not onerous, but they are also not obvious either.

I would expect Visual Studio to implement the best practice by default, but allow me to easily change it. In the next release of EF, could you please do the best solution by default?

re: Working With Large Models In Entity Framework – Part 1

Srikanth — Tue, 25 Nov 2008 13:20:51 GMT

Julie,

Out of the 3 folders in the zip, only one(SubsettingUsingForeignKeys) corresponds to the post today. The other two are for the second part of the post where I will go over type reuse with "Using". Since designer does not support "Using", the Edmx files would not be very useful for these.

I will try to share the Edmx file for SubsettingUsingForeignKeys sample but in the mean while you can put it together pretty easily from the CSDL, SSDL and MSL files following the steps from Sanjay in this post : http://blogs.msdn.com/dsimmons/archive/2007/12/07/how-to-use-your-existing-csdl-msl-ssdl-files-in-the-entity-designer-ctp2.aspx.

Thanks

Srikanth

EF : Comment contouner le problèmes de performance des très gros modèles

Matthieu MEZIL — Tue, 25 Nov 2008 13:53:04 GMT

J'ai récemment été sollicité pour proposer des solutions afin de résoudre des problèmes de performances

re: Working With Large Models In Entity Framework – Part 1

Dariusz Jankowski — Tue, 25 Nov 2008 14:24:13 GMT

I work with model with more than 70 tables and it will grow.

I think that it would be great to be able to work with EDM Model like we work with database model in SQL Server. In SQL Server we are able to generate different diagrams which describes some aspects of relations. It could be also implemented in EDM Diagram in some way.

Helpful may be creating boundaries inside Model so we would work with all model or only with a part of it, but the part would still have relations with other parts (tables in parts).

Example slices:

OrderSlice which consists tables: Order, OrderDetails, OrderStatus, OrderType, OrderHistory

ProductSlice which consists tables: Product, productCategory, ProductFamily, ProductImages, ProductJme, ProductDescription, etc

Is this all has sense to implement in future EF?

re: Working With Large Models In Entity Framework – Part 1

DM — Tue, 25 Nov 2008 14:28:04 GMT

A bit more helpful than Elisa Flasko's comment "Well, big entities are big entities...!" when someone asked this question at TechEd Europe recently.

How to solve a big EDM performance problem?

Matthieu MEZIL — Tue, 25 Nov 2008 14:35:59 GMT

Last week, a customer asked me how to solve a big EDM performance problem? In his case, his model was

re: Working With Large Models In Entity Framework – Part 1

Glenn Gailey [MSFT] — Tue, 02 Dec 2008 22:19:16 GMT

More general information about Entity Framework runtime performance can be found at http://msdn.microsoft.com/en-us/library/cc853327.aspx.

Weekly digest of interesting stuff

Steve Strong's Blog — Wed, 03 Dec 2008 23:44:05 GMT

Weekly digest of interesting stuff

re: Working With Large Models In Entity Framework – Part 1

Norbert Siegel — Tue, 09 Dec 2008 10:08:26 GMT

I worked with 250 tables in the Entity Model an can not split it into 2 or more Entity Models. I used allways pregenerated Views, but the compiletime is much to high. The Runtime Performance is good.

Planed Microsoft a Performance Patch in the next Month ?

解决Entity Framework中大数据模型问题的技巧

BrianLei — Wed, 10 Dec 2008 16:34:05 GMT

EntityFramework的开发领导SrikanthMandadi称这个包含两部分内容的文章为

re: Working With Large Models In Entity Framework – Part 1

Dave C — Tue, 17 Feb 2009 15:41:25 GMT

Hey, we're working with quite a large database and using edmgen2.exe to generate our emdx and .cs files. I found this link very helpful as i didn't know that pre-generating the Views would actually speed everything up. It's created an 80 meg .cs file which VS actually struggles to build.. Once it's built though. It means development is much faster than it used to be. Every time we used to make a change and started up the web site we'd have to wait ages before linq would respond.

I'd recommend to anyone to do this view generation stuff before they work with linq to entities on a day to day basis.

I hope in the next version alot of the speed issues and this hidden stuff is going available as options or properties. Also that linq to entities catches up with Linq to SQL.

Entity Framework ottimizzare le performance

Pietro Brambati Blog — Wed, 08 Apr 2009 17:43:37 GMT

Direi che una buona pagina da cui partire è questo documento su MSDN :Performance Considerations for

re: Working With Large Models In Entity Framework – Part 1

Medyum — Fri, 22 May 2009 13:58:10 GMT

thanks

Comment découper ses entités en plusieurs modèles

Matthieu MEZIL — Wed, 27 May 2009 02:47:43 GMT

Un de mes clients veut développer un ERP avec EF. Sa base contient plus de 600 tables quasiment toutes

How to split your EDM?

Matthieu MEZIL — Wed, 27 May 2009 16:28:11 GMT

One of my customers wants to code an ERP. To make it, he wants to use EF. His DB has more than 600 tables

re: Working With Large Models In Entity Framework – Part 1

Andreas — Wed, 24 Jun 2009 12:00:35 GMT

Does anyone know if there has been some improvement for big database structure? Does the VS 2010/.NET 4 handle it better?

We are in the development process of an application that will grow. For the moment and for the next year we are not expecting a very huge model, but it might become large later on.

What has changed with the new upcoming versions?

Thanks

re: Working With Large Models In Entity Framework – Part 1

radyo dinle — Sun, 19 Jul 2009 17:31:24 GMT

Last week, a customer asked me how to solve a big EDM performance problem? In his case, his model was

re: Working With Large Models In Entity Framework – Part 1

ssk sorgulama — Thu, 23 Jul 2009 17:22:25 GMT

re: Working With Large Models In Entity Framework – Part 1

zerrin egeliler — Thu, 23 Jul 2009 19:41:39 GMT

re: Working With Large Models In Entity Framework – Part 1

juan — Sun, 09 Aug 2009 00:08:42 GMT

una porkeria su Entity Framework..

re: Working With Large Models In Entity Framework – Part 1

Luc — Fri, 09 Oct 2009 06:12:57 GMT

52 entities, 55 associations (Foreign keys)

The Validate step worked slower and slower.

Now it crashes both in VS and at run time ...

EF is big and clumsy. I even wonder if it can be fixed. Many unnecessary features

that should have been orthogonal to the framework not built in.

I actually wanted to use Linq to SQL, that's a lean piece of software. But MS drops it and picks EF as the "winner".

I apologize for being this harsh but it's ridiculous to consider a 50-100 tables system as being big. What's a 500 tables system then?

I concur with Juan above ...

re: Working With Large Models In Entity Framework – Part 1

alex — Sun, 13 Dec 2009 06:52:12 GMT

could your rewrite the petshop demo whit Entity Framework, so we can get a best practice sample.

re: Working With Large Models In Entity Framework – Part 1

Tony — Tue, 22 Dec 2009 19:13:49 GMT

What's wrong with the same type defined in multiple models? For example, with AdventureWorks, tables in the Person schema are related both to tables in the Sales and Human Resources schemas. Why not simply create two models, one for Sales and another for Human Resource, but with Person tables in both models? What are the problems with this approach?