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.
Related
Are RecordSet objects deprecated in the .Net 4.5 Framework? If so, is it possible to include them in a .Net 4.5 Framework project by referencing them?
From my reading, I understand them to be deprecated. I also understand that if your "target" framework is higher than that of the desired reference, the reference cannot be included in your solution (the IDE, e.g. Visual Studio 2013, will not allow the inclusion).
I am looking for a definitive, simple answer as none seem to be available elsewhere (though there are certainly troves of information on the web about RecordSet and DataSet). Again, my question is not how to use RecordSet, but rather whether it is deprecated and - if so - how to include in a .Net 4.5 Framework solution (which I am under the impression is not possible).
If you are able to attach any references, that would be awesome. I am either trying to prove me "wrong" or someone else "wrong".
Here is one of the references I have found that seems to suggest RecordSets aren't really a part of the .Net piece.
There has never been a type named "RecordSet" in the .NET Framework. That name was taken, a COM type that had its hay days in the 1990s. Part of DAO and ADO, COM object models that made it easy to access data. And found its way into plenty of .NET programs, stuck on data providers of the 1990s or injected by code originally written in VB6 or VBA, the most popular programming tools in the 90s.
No, it is alive and well, ADO is not deprecated. DAO got the axe 13 years ago when Jet was removed from the standard distribution. Albeit that it seems to be not quite dead, it is still included with every current Windows version. Microsoft code never dies. COM interop in .NET 4.5, what you use under the covers to consume the ADODB type library, has not changed at all.
There was an ill-fated attempt to make ADO more compatible with 64-bit code, fixing a bug in the type library. Released in Windows 7 SP1, it caused wide-spread dismay and misery so was canceled again. Hopefully you don't have that viral problem.
Otherwise typical of software, it is not like fine wine, it does not age gracefully. Still using Recordset today does not make sense, you'd at least consider uplifting to the System.Data.Oledb namespace. Which is the managed .NET wrapper around ADO.
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.
I've been rolling my own object mapping system for over ten years and my current .NET version is pretty stable and I understand it. I've always kept a watchful eye on commercial developments in this area such a Hibernate but I've stuck with what I know.
However, I keep hearing more about Entity Framework and wondered whether it's time to investigate with a view to replacing my own home-grown system with Entity Framework. Microsoft has had a bit of a checkered history in this field with ObjectSpaces getting cancelled. I assume that project has become Entity Framework. Why did they cancel ObjectSpaces and have they got around the problems in Entity Framework? Is Entity Framework "better" than Hibernate?
Cheers, Rob.
I saw a demo of the entity framework ver 4.0 that will be released with Visual Studio 2010. Looked like it would make you very productive. I think this version will make it main stream for .net developers. More info here.
NHibernate has been around a lot longer and i think that if any .NET mapping library has reached critical mass, nHibernate would be it. Have you checked it out?
P.S. NHibernate is also a port from Hibernate which is THE mapping library for Java. That's a petty good pedigree.
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/
I have been sold on the fun of using linq in areas other than pure database interaction. (See Calling fellow code nerds - Alternatives to Nested Loops?).
We are stuck on 2.0. I have told the powers that be about the ease of updating to 3.5 (we have already migrated to VS2008) but they are wanting a list of "benefits" for upgrading.
Can those that have experience in 3.5 help provide some talking points for the benefits of updating an existing app to 3.5?
UPDATE: Found an additional reason: Microsoft's inclusion of Charting tools for Asp.Net as a patch on top of 3.5! They get their business value, I get the fun...
Can YOU make a case for it? Sounds like you want it because LINQ is fun. Other people are mentioning features that are fun. I've always had a problem selling fun features to management because they aren't very compelling reasons to potentially disrupt an environment.
Honestly, it really depends on what you are using C# for. Are you a web developer, system admin, something else? Taking a general approach, I would use the following selling points (you will need to do some work to prove these things):
Zero-disruption for end-users when upgrading. Upgrading to the new version will be seamless and we will have a thoroughly reviewed test plan for updating all clients to this version. All of our old applications that require .NET 1.x or .NET 2.0 will still work perfectly.
Programmer Efficiency. You could mention how more of the Windows API is wrapped by .NET classes, thus making programmer more efficient because they don't have to P/Invoke as much. LINQ makes your more productive because of x, y, and z. Lambda expressions make you more productive because of x, y, and z.
Ease pains of future OS migration. Moving to WPF now will prepare us for Vista/Windows 7. We won't have to migrate applications using the now deprecated "Windows Forms" to WPF, because we will already be using it.
More applications purchased from 3rd parties will require it, so we will have to upgrade sooner or later.
In the end, you need to prove that at the very least, this move will not cost you money in terms of increased support or testing costs. If you can show it will make you be more productive and it will be a rather painless switch, then you will get your wish.
Maybe you should talk to some Java developers who are probably still forced to develop using 1.3 or 1.4 despite 1.5 being out for over 3 years and 1.6 for a couple... it appears platform consistency across the business is often of greater importance than the benefits of using the latest and greatest.
Also remember that 3.5 is just additional BCL libraries. You are still running on CLR 2.0. Same is true for 3.0. Usually when people find out that the underlying framework is the same and that you are just adding in new libraries they are more likely to go along with it.
You don't need .NET 3.5 to get LINQ or C# 3.0 features. You can implement your own LINQ for .NET 2.0. I am using C# 3.0 all over the place in my .NET 2.0 application. I don't know the full details on how to start the conversion process because I didn't set it up myself. This might be a good link for you: http://www.danielmoth.com/Blog/2007/05/using-c-30-from-net-20.html.
http://msdn.microsoft.com/en-us/library/ms171868.aspx
Transitioning onto 3.5 would help you reap the benefits/ features of:
LINQ to (Entities/ XML / Objects / Datasets etc ).
WCF, WF and WPF.
ASP.net MVC where MVC is kind of a de facto standard in other
platforms like Ruby/Python which
allow you pure HTML/ Javacript based
development.
ORM options with ADO.net Entity
Framework/ Linq to Sql
4.
With a few addons you can have
support for dynamic languages
like
IronPython/IronRuby.
Oh ya I almost forgot ADO.net Data Services..one of my fav.
These are the few benefits that immediately come to my mind.
In my experience, the addition of LINQ and Extension methods alone have made many previously arduous and/or time consuming tasks much easier and faster. The increased developer productivity from that alone is worth the upgrade effort IMHO.
Lambda expressions are awesome. There is no end to the places where I find that lambda expressions help me out in a very concise and readable way.
Automatic properties, while being a simple concept, really help making the code base smaller and clearer.
Also, I sencond the extension methods.
Before I even opened this question I had my answer: LINQ - it's one of the greatest extensions ever in .NET - I love it. It took me a few days to figure out, but now I've got it, I use it all over the place. The ability to query collections and arrays is worth the upgrade alone in my mind.
Decreased development time (and therefore increased ROI)
Less time wasted finding workarounds for .NET bugs that've been fixed in newer releases.
Extension methods for native types (in a similar fashion to JavaScript prototyping)
LINQ extensions - they take a couple of days to get your head around, but it's awesome!
LINQ to XML makes working with XML so much simpler
LINQ to objects/collections
A nice new 3.5 poster from Microsoft that you can pin up in your cubicle.
As a manager if I have a happier more productive team that is producing more in less time, then its a no brainer.
Ask yourself this: Will the developers be more effective and will their increased productivity actually increase benefit to the company or reduce corporate costs once you've considered the upgrade/transition/installation on the servers/additional testing etc? If the answer is truly yes, then do the upgrade and quit arguing about it.