Salakhetdinov Shamil
mcp2004 at mail.ru
Sun Apr 26 03:09:29 CDT 2009
Hi Gustav and all, Great, we have now some more stuff to discuss/test :) Yes, it depends. No, I (think) I'm not a hardcore SQL/T-SQL programmer, and I did have developed and I'm supporting applications with advanced business domain model/business rules - all that business logic implemented using object layer in pure C# on top of MS SQL SPs/UDFs... The main issues with EF for me currently are: - 1) "PITA mapping" of SPs to entities or even absence of an option to map some kinds of SPs; - 2) source code control issues because of EF .edmx (model) keeping all the information; - 3) being unsure on the fate of EF after .NET Framework/VS2010 release (based on a pity faith of LINQ2SQL, which development was stopped by MS) <<< and the EF creates all the SQL needed to carry out the operation and sends that to the database server to be processed. >>> Yes, that's clear - the issue is that most of the modern (enterprise level) applications do use CRUD SPs as well as select SPs (returning rowsets and scalar) in between of Data Access Layer code and database tables. There are several reasons to use them - one of the main of them is security AFAIU - and the folks who are noting that EF currently is a PITA to map such CRUD and select SPs to entities are correct in my opinion. My experience (and others as far as I see e.g. from Rickford Lhotka's CSLS.NET) shows that even the most advanced modern enterprise level application developed using Business/Domain Level Model(s) implemented in code (C#/VB.NET) - all have a common denominator: CRUD and select SPs. And when CURD and select SPs are used then such application development is manageable - as soon as built-in/on-the-fly generated SQL is introduced applications development starts to become unmanageable... I can be wrong, Gustav, yes, it all depends, and EF ability to generate advanced SQL is a useful feature (done the similar things here a long ago, of course without advanced optimizations) but the folks' concern on EF "currently PITA" mapping to SPs is also my main current concern... All and every application if you look at it on a very generic level does the following: - 1) stores/updates/deletes data (with validation which can be done on both front- and back-end layers with some overlap); - 2) extracts data from db into business/front layer to make some processing and then goto (1) and using CRUD and select SPs layer clearly shows that application development is rather easy activity - but when we mix the things of data manipulation/storing with business logic (whatever way we do that: using built-in manual SQL, datasets, EF with on-the-fly SQL generation...) - then we're getting lost... Sorry, if the above my writing looks like an excessive unreasoned by your experience generalization but this is what my experience tells me - and this is why I'm concerned with other folks on SPs mapping issues in EF... The main current issues with EF AFAICS: - folks are very concerned with the fact that LINQ 2 SQL development was stopped and that EF might have the same fate - why use the latter then? (my guess MS is currently "betting" on "EF" and therefore the chances it becomes "dead" are low but MS proceed with EF development a bit slow on outer world audience opinion) ; - EF speed. Well, my guess that speed issue could be a concern for large enterprise applications with thousands of simultaneous users - and the question/issue here is not with optimization of on-the-fly generated SQL but with the fact that every framework introduces a code/mapping layer producing some bytes on compilation, and even if that would be a few bytes for every entity object (but more than, say CSLA.NET or NHibernate introduce), they will play their bad role for enterprise level systems with thousands and thousands of simultaneous users - yes, the issue can be usually solved by scaling hardware but that's not always possible and in most cases is very pricey. - Related speed issue is that on-the-fly generated SQL used in e.g. intensive cycle processing of data will work rather well with small test sets but when in production such coding would become a "bottleneck" - of course such issue can be catched early by testing ... - folks are also concerned on the absence of lazy-loading, which could also results in speed issues... - inability to easily map select SPs returning rowsets as well as scalar SPs (I can be wrong, got known on that issue from Internet, checked just once, maybe missed) - this is one of the main issues for many developers and for me personally; - tightly coupling of EF with backend DB is also an issue for folks because that tighly coupling makes (unit) testing dependent on backend; - the version control and conflicts issue - I agree with folks that this is a serious issue - why MS didn't do it by having dedicated file for every entity/association/... and a "joining" .edmx file - that's is an open question for me/proposal to MS :) - a kind of kidding :) ... Recap: - I personally do not care on EF speed issues as I have checked and I see that EF is a light framework, and as Gustav noted that on-the-fly generated SQL optimization is solvable and is ongoing (there in MS) task and as (in my opinion) carefully tested business layer programming should also let to avoid "indirect" speed issues even without lazy loading; - I personally am very concerned on the "currently PITA" mapping of entities and SPs as well as I'm not sure will MS continue EF development after VS2010 release or not. That's it. Very important advantage of EF for me is that .edmx can be put into a classlib and used from front-end and other kind of projects - and when used with WinForms similar to DataSets RAD way of forms' design is working for EF .edmx located in a classlib (and that would work for WPF in VS2010 similar to WinForms). Gustav we can test speed issues in our ongoing Northwind.NET project: - I have a custom relatively lightweight ORM mapping framework, which I can use to create BL and DAL C# objects as well as CRUD and select SPs for Northwind.NET - I will/can make such coding available in one of the future versions of Northwind.NET, and then we can also create .edmx without any SPs and we can write some tests to compare the speed of processing: I expect there will not be that much difference - OK? (we can also try to use CSLA.NET as I expect it is a bit lighter than my framework is (but I do not have experience with CSLA.NET)) Thank you. -- Shamil P.S. Once again: SPs are used here because of security and manageability reasons not because of the speed reasons... -----Original Message----- From: "Gustav Brock" <Gustav at cactus.dk> To: <dba-vb at databaseadvisors.com> Date: Sat, 25 Apr 2009 23:07:38 +0200 Subject: Re: [dba-VB] ADO.NET Entity Framework - to use or not? > 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 > > > _______________________________________________ > dba-VB mailing list > dba-VB at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-vb > http://www.databaseadvisors.com >