Supposedly this release includes 2 features I'm interested in.
Enums support
Model can be broken into multiple files.
I don't want to install it because of issues people report, so I will ask questins here :)
Is there any wild guess when we get production-ready version of this stuff?
My issue with EF right now is that it get's really slow after 100+ tables. Do I understand correctly that new feature with multiple diagrams will help with scalability?
Its in EF version 4.1
Code first method drops the EDMX designer all together, its all in code using classes, and if a slow designer is a a big thing for you, code first method is definitely for you.
Related
I've been dealing with EF in my project for 5+ years. It's database-first and because of huge overhead migration to DbContext will result in, I'm still dancing with ObjectContext.
It is nice to see improvements of runtime performance delivered in each release, though we all know that last official release is missing view generation mechanisms because of mapping api been hidden. This is fine for relatively simple entity models, but I'm having a complex one, warm up time is not acceptable.
I've installed 6.1 beta recently and it looks like generated views do the job, and I'm thinking of making it part of my project's next delivery.
My question is about 6.1 prerelease version: is it beta because of not everything from promised 6.1 backlog is done(were, though, some things are completed and tested) or is it beta because everything to some extent, is still being developed?
I'm hoping for first case scenario and maybe someone can help me with figuring this out, any kind of feedback is welcome(don't tell me "beta is beta", I know :) ).
Thanks!
Like suggested by #abatishchev, I've installed EF 6.1.0 RTM instead.
I am currently working on a project where I want to use the Entity Framework
for the first time. I read much information in the books of Lerman/Miller,
in MSDN, the ADO.NET blog and here on stackoverflow about the most recent
developments regarding the DbContext API and the Code First Migrations
capabilities available since EF 4.3.
Since especially the latter are really great, I wondered whether in the meantime
it is possible to do the same working "Model First" centered? Is it possible to
do migrations based on the visual EDMX designer (instead of the code) after
creating the code and the database from it?
I found a pretty recent link (2012-04) saying that it is not (in EF 4.3):
Using EF4 migration tool with model-first approach
Secondly, I found information that old code and database tables are
overwritten when trying to regenerate them from the EDMX designer?
But the info I refer to is about the Power Tools:
http://blogs.msdn.com/b/adonet/archive/2012/04/09/ef-power-tools-beta-2-available.aspx
Reverse Engineer Code First
This command allows one-time generation of Code First mappings for an existing database. [..]
• Running this command multiple times will overwrite any previously generated files, including any changes that have been made to generated files
Is this restriction only specific to the Power Tools Reverse Engineer Code First
or does it expand to the EDMX designer in general, especially the "Model First"
approach, too?
Furthermore, in the above article I found:
View Entity Data Model (Read-only)
Displays the Code First model in the Entity Framework designer.
• This is a read-only representation of the model; you cannot update the Code First model using the designer.
And the same question applies here.
So is there currently a way with full round-trip modelling without data-loss
(code and database) and keeping the EDMX file writable, preferrable following
"Model First"?
From which verson of EF on is this (already or planned to be) supported, which
version of .NET should I target then (4.0 sufficient?) and will this work with
Visual Studio 2010 Professional? Could you give a rough estimate for the date
you may will have implemented this?
This would of course be awesome and a huge breakthrough! I think I can only
roughly imagine how much work this would be and am aware that you are fully
working at your limit already. I want to thank you for your great work so far
and encourage you to keep it up.
If I understand your question correctly you are after Migrations for the EF Designer (i.e. update the model in the designer and have the database incrementally changed). This isn’t currently supported, it is on our backlog to address but we don’t have specific plans for a particular release. One of the things we need to work out is whether we should just integrate/extend the existing Code First Migrations feature to work with the EF Designer or whether we need something that is a bit more designer focused.
Obviously things can change, but at this stage I wouldn’t be expecting us to start working on this feature in the next 6 months. Beyond that it’s going to depend on what features we see folks asking for… so I would create a new feature on http://data.uservoice.com and get folks voting on it.
~Rowan
Because of specifics of my current project, I have to keep using .NET 2.0. Are there any Entity Framework-like ORMs for .NET 2.0?
I'm absolutely OK with non-LINQ interface. Syntax like users.Where(u => u.Age > 100).Count() is fine.
I need to use DB-first approach: I already have a DB with about 30 tables and just considering the ways of simplifying work with it. So, I'd really appreciate if it's possible to generate the required code from existing DB.
It's also OK if it won't generate all the required code but provide the way to describe DB structure manually (using attributes, for instance). Basically, I just want to be able to build more or less sophisticated queries without messing with real SQL, SqlParameters and DataSets/DataTables with all these int.Parse(row[12].ToString()) (that's a legacy code I'm trying to get rid of)
Also, that would be great if I'm be able to "override" some particular "queries" with calls to existing stored procedures.
The most important is p.2 - DB first. Is there anything of this kind? Or am I absolutely wrong with my thoughts? Will appreciate any ideas.
Your best option is to check out NHibernate. Many (most?) people consider consider it more feature complete and powerful than EF 4.1, plus there are plenty of resources here on stackoverflow and the rest of the web to guide your development process.
Be sure to look into Fluent NHibernate to make mapping from your database to C# objects easy. The alternative of editing XML files is complex, clunky, and time consuming.
Note that you might need to use an older, but still completely functional, version of NHibernate that is compatible with .NET 2.0 (I think, but am not positive, that the more recent versions require .NET 3.5).
There is plenty of available ORMs but some of them are commercial (LLBLGen Pro). The good choice for you is probably NHibernate 2.1 (I think NHibernate 3.x requires .NET 3.5).
You should also thing about moving forward to a newer .NET version. Starting a new development on .NET 2.0 should be avoided and involving a new technology to existing old code base IMO spoils application's architecture and maintainability.
Edit:
So, I'd really appreciate if it's possible to generate the required code from existing DB.
The most important is p.2 - DB first.
ORM and code generation are two different areas. DB first doesn't mean code generation - it means mapping to existing database without needs to change the database. It is not point of ORM to generate code for you. The point of ORM is to allow you to map DB to classes and abstract querying. If the most important point for you is code generation you should look for something else then ORM. NHibernate doesn't have such code generation included but there are some additional projects which add similar features.
I have been developing an inherited a product for the past couple of months that employs Microsoft Entity framework using the persistence ignorant POCO approach. I use a T4 templates to generate my POCOs which include Fixup methods.
My problem is that is just keep running into too many problems that I believe are inherent flaws in the design of Entity Framework. When I fix one thing another issue pops up.
My question is from a truly professional point of view where teams are writing medium to large scale revenue generating applications for desktop and web what are peoples experience and do people actually use Entity Framework in the "real world".
I realize this is a bit of an open question however I would like to survey peoples view to determine if I am fundamentally missing some core concept of EF.
Which version of EF? I'm using 4.1 and it's working just fine. You don't mention exactly what you're running into, but If you list specific issues, perhaps we (collectively) can help.
So far I did not like EF. Although I liked the tools and how easy it was to create certain types of mappings and relations, Other types were a pain and the Linq support in EF wasn't so great (couln't create my own filter extension methods).
Is the new EF in .Net 4.0 better. Given what I have stated so far is there a chance I will like it.
The reson I ask this is because I use linq2sql a lot and do not like the feeling that the platform I am using is about to go obsolete. I would like to upgrade to something that is as similar as possible to what I already have.
Thanks for your opinions
It's only an opinion, but I believe that the new EF will be much improved. They will almost certainly have some kind of migration path from Linq to SQL. Whether it will look like Linq to SQL is another story. The two tools have somewhat different philosophies.
While EF will be designed for enterprise scenarios, it is my hope that the next version will still be lightweight enough to serve as an adequate replacement for L2S in small application scenarios.
I am really optimistic about EF 4.0 from all that I have seen thus far. The beta release is already available to MSDN subscribers and it addresses a lot of the concerns around POCO, Persistence Ignorance, N-Tier support and all that. I continue to recommend reading the ADO.NET team blog as a great resource for what's changed.
You can't compare it to the first release because this is a very big overhaul and a lot has changed.
That said, initial adopters always get the worst of it because they are the first to run into bugs and new problems while the late comes can benefit from the lessons learnt by the early adopters.
There has been a lot of improvements. I have ran in to a couple of strange issues but nothing unsolvable yet. It took me a few hours to understand how POCO works meaning they spent a lot of. I recommend you download VS2010 and play around with it yourself!
Have a look at this presentation, and you will know why EF worth your time.
How to Think Like the Entity Framework Presentation: http://blogs.teamb.com/craigstuntz/2009/09/11/38394/