Revisiting LLBLGen/EF and the future

Posts   
 
    
gabrielk avatar
gabrielk
User
Posts: 231
Joined: 01-Feb-2005
# Posted on: 05-Aug-2015 21:18:42   

Hi All,

Let me first honestly confess that I'm trying to take a short cut here, hoping to benefit from other people's experience with the Entity Framework instead of spending a couple of hours/days on it myself.

Since I've started using LLBGen 10 years ago I haven looked back, nor sideways. Now I've just joined a company (that's a first time for me wink ) and one of the responsibilities is setting up the development team/capability. Of course, I am thinking about using LLBLGen, but I will have to defend that choice. For that reason I was wondering if some people could point me at the differences between the two and if it is still defendable to use LLBGen (mainly the runtime).

Thanks a lot!

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39753
Joined: 17-Aug-2003
# Posted on: 13-Aug-2015 10:42:26   

EF6 is EOL (they barely fix issues anymore) and EF7 is a limited version and not stable yet (expect it to be unstable for at least a year from now), and has less features than Linq to sql. EF doesn't have a designer worth using, so you're likely better off with ours for EF anyway simple_smile EF7 won't have a designer at all, besides some one-shot tooling to generate Code first code.

EF6 is terribly slow (see: https://github.com/FransBouma/RawDataAccessBencher ) and not by a margin but massively slower than our runtime. They have pocos and we don't but as nowadays people create new models on top of entity models anyway for using the data it's not important anymore.

EF doesn't really have support like we offer: a bug isn't fixed quickly nor is your question answered quickly (or you must ask it on SO, but then you're depending on whether a random stranger is willing to answer your question).

Make no mistake: their rewrite is done for a reason, namely EF6 is a terrible ORM, both from an architecture point of view as well as a usability point of view (e.g. migrations have lots of issues (and they therefore killed it in EF7 for something different), as well as graphs of entity objects which have to be inserted and updated in one statement don't work without manual labor as their change tracking is inside the context, not inside the entities).

But of course, I'm 'biased' wink

Frans Bouma | Lead developer LLBLGen Pro
gabrielk avatar
gabrielk
User
Posts: 231
Joined: 01-Feb-2005
# Posted on: 24-Aug-2015 16:12:36   

Thanks! That gives enough starting points to build a case.