Gustav Brock
Gustav at cactus.dk
Sat Apr 25 16:07:38 CDT 2009
Hi Shamil There probably isn't a definitive recommendation - as always, it depends - but I must say I find it quite fascinating to "leave" the tables and views and work with objects instead. If you are a hardcore SQL/T-SQL programmer, you may never feel at home in the EF environment. I am not such a programmer - I know my SQL, but T-SQL I only work with out of necessity - so I don't miss it. To me the EF is a challenge because it is very hard to forget the tables and SQL and a lot of handwork is required up-front to create the model wrapping the tables and views, though I think this pays of later. As for the quoted comments: I find the discussion about the stored procedures to be a misunderstanding - the concept is indeed not that you should sit down and program stored procedures for each and every common task for each table - it is the other way around: the EF creates all that plumbing stuff for you; if you request a change of a property of an object you do that, and the EF creates all the SQL needed to carry out the operation and sends that to the database server to be processed. Regarding the whining about the version control and conflicts, it is not different from the normal datasets - two developers can't add or modify DataTableAdapters at the same time. If this is likely to present an issue for a project, you will have - as you have done in our Nortwind.NET project - to create separate datasets for, say, each report, form, or something else and - before a developer start modifying it - a lock must be posted. Or do I miss something? My major concern is speed. Some tell that the SQL generated by the EF is quite convoluted. I haven't looked into that. In my opinion this has nothing to do wether the concept is good or bad but is a simple (or rather difficult) optimizing task which is an ongoing task. /gustav >>> Salakhetdinov Shamil <mcp2004 at mail.ru> 25-04-2009 20:45 >>> Crossposted to northwind.codeplex.com --- Hi All, I have spent some time today investigating ADO.NET Entity Framework, and reading articles and opinions on its usage, current status (.NET 3.5 SP1) and the future .NET 4.0/VS 2010: as far as I see this is a promising technology but it looks like it is not yet ready for enterpise level development. And what is your opinion? ADO.NET Entity Framework http://en.wikipedia.org/wiki/ADO.NET_Entity_Framework Stored Procedure Mapping http://blogs.msdn.com/adonet/archive/2008/03/26/stored-procedure-mapping.aspx Using stored procedures with ADO.NET entity framework http://blogs.infosupport.com/blogs/willemm/archive/2007/09/11/Using-stored-procedures-with-ADO.NET-entity-framework.aspx ADO .NET Entity Framework Vote of No Confidence http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/ <<< When the Entity Framework is used on projects staffed with more than one developer, merge conflicts occur whenever two developers make changes to an entity diagram. Since the diagram tool is the default and intended tool for making changes to an entity model, the frequency of this problem is will result in an unacceptable level of friction in team member interaction and change integration. >>> http://forums.asp.net/t/1363046.aspx <<< So in short, EF as it stands now is worthless for real life use. I guess I've wasted several weeks of my life rewriting my code for a technology that should have been released as incomplete and only in beta. >>> http://blogs.msdn.com/adonet/archive/2008/12/02/migrating-from-linq-to-sql-to-the-entity-framework-stored-procedures-for-data-retrieval.aspx <<< NO ONE CARES. EF is an overcomplicated piece of junk compared to L2S. If we're going to migrate our L2S DAL over to something else, it won't be Entity Framework (which you'll probably abandon next year in favor of something else anyway!) >>> <<< Linq to Entities simply does NOT work in a real world environment. Don't bother trying to use it with stored procedures that return nothing. I have to wait for VS2010 to get something that will supposedly work? THIS was supposed to work. You told us to move from linq to sql to linq to entities and I did all the conversions for a piece of junk that has put me weeks behind in development and still doesn't work! I'm ready to give up and simply use an ORM that actually works and actually has support and working examples. Why release a technology and tell us to use it when you know it is crippled?!!!! >>> Thank you. -- Shamil