back to article Entity Framework goes 'code first' as Microsoft pulls visual design tool

Microsoft will retire the visual design tool for its Entity Framework (EF) database tool in the upcoming version 7, in favour of a text-based “code first” approach. Entity Framework is an object-relational mapping (ORM) tool. It lets developers work at a higher level of abstraction, coding with application objects rather than …

  1. Anonymous Coward
    Anonymous Coward

    Nice

    That training course work recently sent me on to keep me "up to date" with the latest tech, is now suddenly far less up to date than I first thought.

    1. El_Fev

      Re: Nice

      Its changes like , which made me give up even bothering to try for an MSCD. You study for something and then literally a week later, its deprecated!

      Look at XNA just dumped overnight.

      1. Anonymous Coward
        Anonymous Coward

        Re: Nice

        True, plus Silverlight and the whole GUI fiasco.

        MS are currently making it very hard to motivate yourself to spend time learning their new tech. It's often a bad investment.

      2. RyokuMas
        Happy

        Re: Nice

        "Look at XNA just dumped overnight."

        Ah, but therein lies irony. For now, thanks to Monogame, the XNA framework lives on on pretty much everything but the Xbox.

        So thank you Microsoft for developing the tools that now ultimately leave me able to code for Playstation 4, and Android and iOS mobile devices...

  2. Jonathan 27

    "Sigh"

    It wasn't long ago that Microsoft was telling us to use the diagram-approach. I've got a large project that uses it and I doubt we're going to move to code first. Perhaps when entity framework 8 is released and they've worked out the rough edges.

    1. Anonymous Coward
      Anonymous Coward

      Re: "Sigh"

      I see the logic behind waiting for EF8 (or at least EF7.1), but I can't imagine that it'll be so difficult to convert an EDMX approach to code-first, it's just a case of making the generated classes more accessible than they are currently (i.e. not hidden away behind the T4 text template) - all the work is then handled through the DbContext, which you will have control over rather than it being auto-generated by the EDMX. Admittedly, if it's a complex schema then you end up with a lot of complexity in your classes, but that's still the case with database-first, it's just the complexity is abstracted away - thereby introducing the ORM "black box" mentioned by the article.

      On a personal note, I can see huge advantages in guiding developers away from the EDMX approach - using code-first gives you a much better appreciation of how EF works - using the designer it's easy to be left with little to no idea of what the DbContext class is responsible for, and relying on abstractions without any appreciation of what's happening behind the abstraction is what leads to software bloat and inefficient practices.

  3. Irongut

    "Plain text code is also easier to work with, for example in source code tools, diff tools (comparing two versions) and the like."

    XML files are plain text so this is complete nonsense. XML works perfectly with source control, diff, etc.

    1. Tim Almond

      EF Diff

      Yes, they do, but that wasn't the problem. It was that everything was in one file. A couple of people changed or added some tables and that meant manual merging that was ugly and prone to errors. You try looking at a two huge EDMX file and working out what changed from the last version.

      The last project I worked on was old EF and the simplest thing was to only have one person at a time updating and checking in the EDMX to avoid problems.

      With Code First, developers can be making changes in and even if you get a conflict it's easier to resolve. The history is easier to see as you can see a list of all entities in a changeset and look at each individually. Plus the migrations stuff means that you have real DB source control. It enforces developers working out all the base data that has to be there, which means you're less likely to get a cockup because someone forgot they needed to setup all the country codes when you go live.

    2. Anonymous Coward
      Anonymous Coward

      Not necessarily nonsense in this case - if two devs working on one model simultaneously check in and source control merges the EDMX file, it can lead to inconsistencies between that and the designer generated model classes. If that happens, then the project fails to build. In my experience, the quickest way to deal with this situation is just to generate your model from scratch. This simply won't happen with code-first as all that has to be merged are the classes - the worst that will happen is that your DB will be out of sync with your classes so you just run Update-Database and all is well.

    3. Bronek Kozicki

      No, XML does not work perfectly with source control, diff etc.

      XML as a format suffers from tight internal coupling and low cohesion - because it's universal and low level tool, as compared to domain specific language (say, SQL). Meaning, you make a small change in one place (in whatever domain specific tool you are using) and it's reflected in dozens (if not many more) of places in resulting XML. This is what you will see in source control, diff etc - instead of the one change you actually made at the higher abstraction level. This approach does not lend itself very well to history inspection, merging and other operations you would normally use source control system for. Instead, you have to be extremely careful because merging of the most innocuous changes done concurrently by two developers is most likely not going to be an easy task.

      This is also why it is preferable to work with text format of domain specific language (e.g. SQL in case of relational database design) rather than XML. Even though I dropped developing databases many years ago, I'm glad Microsoft has seen the light.

  4. Anonymous Coward
    Anonymous Coward

    So this is like the Play framework evolutions?

    Not sure if it exists in other environments, but if you're on the Java camp you could do a lot worse than checking the Play Framework. It is model driven and has the same concept of "evolutions" No fancy diagramming tools, however.

  5. Anonymous Coward
    Coat

    Time for something new?

    Whilst this isn't a total surprise as they appear to be going code first with everything else in .Net, I'll miss the design tool it was very useful.

    They seem to get bored and drop support for things in the .net system a lot these days, I'm tempted to go back to Java dev work or maybe even give Node.js a try as I'm not really liking the direct .Net is going.

    I'll get my coat.

  6. Anonymous Coward
    Anonymous Coward

    don't understand the logic

    I get people who're selling the benefits of MVC as speed, and they then go and 'upgrade' their db to EF to be down with the kids.

    Considering even MS's own figures show it several times slower than the old fashioned route, what's the point? Maybe it makes you seem groovy, but taking such a massive performance hit because it's new and funky doesn't really make sense.

    1. Tim Almond

      Re: don't understand the logic

      several times slower? Produce those MS figures.

      1. xyz Silver badge

        Re: don't understand the logic

        Hand coded (using a SqlDataReader ) 47ms

        Dapper ExecuteMapperQuery 49ms

        ServiceStack.OrmLite (QueryById) 50ms

        PetaPoco 52ms

        BLToolkit 80ms

        SubSonic CodingHorror 107ms

        NHibernate SQL 104ms

        Linq 2 SQL ExecuteQuery 181ms

        Entity framework ExecuteStoreQuery 631ms

        from https://github.com/StackExchange/dapper-dot-net

        I fu**ing hate EF, but I love .Net MVC

    2. Anonymous Coward
      Anonymous Coward

      Re: don't understand the logic

      Not several times by any means but definitely slower, every layer of abstraction adds extra latency, it's all a trade off of usability vs performance.

      Writing SQL manually can be error prone if you're not an expert and you're trying to rattle the queries out. EF prevents you from making some of those mistakes and it gives you a lot of benefits such as change tracking, UoW, etc, but at a cost that is worth it for a great many people.

      "Some developers therefore prefer to avoid EF; but integration with other Microsoft frameworks like ASP.NET MVC means that avoiding it can also require some effort."

      Has the writer ever used MVC or EF? All that is required is to delete a few classes and uninstall the Nuget packages and it's as if it were never there, it doesn't get much easier than that.

  7. Mephistro
    Meh

    My experience with this kind of tools...

    ... might be a little outdated, as the last time I used "seriously" one of these tools was circa 2005 with -sigh- MSaccess (hence the quotation marks around the word 'seriously' ;-).

    But from what I remember from that visual design tool, it had similar issues. It was a quick and dirty way of defining queries and database relationships and it generated code that was difficult to read/debug and sometimes very inefficient for non-trivial tasks. On the other hand you could do in a few minutes a work that, using a text interface could take a few hours.

    Now what riles my about MS retiring this tool 'cause it has issues' is that, instead of fixing the issues -i.e. making the tool better, more efficient and able to create more readable, structured and documented code- they go the easy way and just remove it. They seem to stick to their policy of removing from users of their products the ability to choose, as they did with things like the ribbon and the start menu in Windows 8. They don't learn, do they?

    I'd bet that they couldn't find enough interns to rewrite this tool, so they chose to scrap it instead. :-)

    1. Roland6 Silver badge

      Re: My experience with this kind of tools...

      I would tend to agree that MS are being a little daft here. So the visual tool has a limitation due to the way it generates stuff, so what? That is a common problem across all the rapid development tools I've used over the years. The key was to understand the limitation and work around it if necessary. So in the case of DB tools use the tools to facilitate prototyping and initial development then take the output and hand craft the necessary revisions to give the performance or scaling required.

  8. colinb

    And this is why

    for critical systems we use LLBLGEN or Dapper for quick and dirty projects

    They should just put EF out of its misery

    SharePoint Designer another casualty of 'we're removing the visual editor because of HTML5, we're bored, its a Friday or this or that'

    Visual editors and quality patches are all too difficult for the current crop of MS devs

    1. bpfh
      Headmaster

      Re: And this is why

      <rant>

      I was brought up on C, PHP and VB6 + VBA, so I know both from the code up and from the GUI down methods, and for some time, the idea of using a GUI, even for basic, simple, no frills "get some user input in a user friendly interface, do somthing with it, and please get it delivered in 2 hours" environment, you will have a hard time beating a form based event driven approach, it works.... then the Linux kiddies spouting W3C compliance started taking over the shop, code is everything, it must be pure, we don't care if the end user can't understand, and oh, it will take us a day to write the interface, by hand, in XML, and we have not even started thinking about the logic yet...

      With Adobe Flex, hand building a GUI with XUL and XAML was the new Apache managed future. a GUI interface design? Na, too easy, only noobs with Frontpage do that...

      20 years ago, the buzzwords were RAD, drop in controls and WYSIWYG prototyping. Dev tools were popping up left right and centre. Access was thought of as a powerful database tool that an accountant could use to pull and query data - and they did, Windows apps became easy with Windev, VB and Delphi. AOLPress, Amaya, Frontpage and Dreamweaver gave people a chance of building their web pages, and started the interest in the net, and shaped what we have today...

      Today though, it it's not coded by hand in (notepad|vi|notepad++|eclipse), you are doing it wrong, and I personally, as a reactionary old fart, think that we are slowly sinking back into the dark ages, efficiency be damned.

      </rant>

  9. Henry Wertz 1 Gold badge

    I ran into serious problems with EF

    I ran into a serious performance problem using EF. This could of course be worked around manually but.... so, LINQ supports data types that are queries, using a .NET array type where the variable itself uses lazy evaluation, it doesn't retrieve or compute the result until your program actually accesses the value. For example, you can point your GUI to one of these, have it show 10 records from a query, if the query has 50 results it will only retrieve 1-10 until you scroll down. Well, in theory -- EF doesn't support these, it loads the whole enchilada (all 50 records) into RAM and then "lazily" loads values out of that in-memory copy as you use it (it doesn't generate any optimized SQL at all.)

    1. Uffe Seerup

      Re: I ran into serious problems with EF

      "LINQ supports data types that are queries, using a .NET array type where the variable itself uses lazy evaluation"

      No, that is not how LINQ composes queries. LINQ supports IQueryable<T>. IQueryable can be composed with other queries, more clauses etc. In general, when you compose using IQueryable, the result will also be (should also be) an IQweryable.

      "it doesn't retrieve or compute the result until your program actually accesses the value"

      (Guessing here) It sounds like you are talking about a *property* with a *getter* which is then evaluated on each reference. If it does not return an IQueryable - it cannot compose lazily with other queries. If it is indeed an "array" type as you describe - that is definitively not the way to do it.

      "For example, you can point your GUI to one of these, have it show 10 records from a query, if the query has 50 results it will only retrieve 1-10 until you scroll down. Well, in theory -- EF doesn't support these, it loads the whole enchilada (all 50 records) into RAM and then "lazily" loads values out of that in-memory copy as you use it (it doesn't generate any optimized SQL at all.)"

      EF does indeed support paged queries. Use Skip() and Take(): Skip to skip n results, Take to retrieve the next m results. I suspect that you may be using some GUI element that does not use this EF feature.

  10. Chris Beach

    Phew

    Just started learning about EF and our first major app is being done code-first, it just seemed from the articles and sites around that it was the more flexible route.

    Besides if I want a diagram the class diagram that VS can generate from any class structure seems enough.

  11. kmac499

    All change Yet Again...

    Who in their right mind would build a long term, 3-5yrs, project or product line on any microsoft 'technology' i.e. set of proprietary function libraries \ development tools.

    Let alone invest in self training and certification at the huge double cost of the course fees and lost earnings whilst on the course..

    The list of discarded and abandoned products just get's longer..

    1. GavinC

      Re: All change Yet Again...

      Who in their right mind would build a long term, 3-5yrs, project or product line on any microsoft 'technology' i.e. set of proprietary function libraries \ development tools.

      All technologies evolve over time, whatever technology you use at the start of the project will be outdated by the time you finish.

      Just because Microsoft have dropped this feature from future releases, doesn't mean everyone using it is now forced to switch. All projects using EF6 and Model First can continue to do so, they just cannot upgrade to EF7 without changing their database code.

      It's like saying you wouldn't develop a 5 year project for Windows because by the time you finish Windows 12 will be released. If you start with Win7, keep using Win7.

      1. kmac499

        Re: All change Yet Again...

        My concern is from a straight forward manufacturing point of view.

        We do have products in the field that users loved but had to bin when XP ended. No realistic cheap upgrade was possible.

        If I was to continually adopt the latest shiny shiny techniques and tools from MS My first cost would be in staff training.. The second hit would be in productivity as the new shiny is found to have a few tarnished edges and people get up to speed using it. Then assuming we get the item out of the door, it's the ongoing maintenance and lifecycle support cost that would worry me. Staff turnover Would erode the skill base and any new recruits may be interested in looking for a post in the latest shiny rather than a maintenance job..

        MS are by no means unique in this but in what other industries would a major manufacture regularly dump core ways of doing stuff and change the paradigms completely.

        2014 Ford announces new hybrid AC engines

        2018 Ford announcs new all electric DC Engines

        2020 Ford announces Trams who needs their own cars anyway

        2023 Ford announces the personal tram powered by Fairy Dust.. etc..

        1. Mark 65

          Re: All change Yet Again...

          "If I was to continually adopt the latest shiny shiny techniques and tools from MS My first cost would be in staff training.. The second hit would be in productivity as the new shiny is found to have a few tarnished edges and people get up to speed using it."

          Why would you feel the need to *continually* use the latest? Use the latest now by all means if it does the job but never upgrade for upgrade's sake.

  12. Trevor_Pott Gold badge

    Microsoft's war on ease of use continues unabated.

  13. dan1980

    "The snag with ORM tools, EF included, is that while they solve some problems, they introduce others. They can be less efficient than writing your own SQL, with a common problem being that the ORM tool may retrieve more data than the application actually needs for a specific operation, whereas a developer can request only the exact fields and rows that are required. The ORM layer can also be a black box that is hard to debug; you have to trace the SQL that it generates and puzzle out why it is wrong."

    That's a whole lot of 'cans' and 'mays'*.

    Now, I am not the shadow of a developer but it seems as though this is MS's way for forcing people to code the way MS wants. If someone is already hand-coding these bits then what harm does it do them to have the visual tool sitting there available but unused? Does having it available make their hand-written code less efficient?

    It seems that this is removing an option and nothing else. If so, how does this decision benefit the people using the software? Those not using it to start with experience no change and thus no benefit while those who are using it now have a feature they used vanish.

    Those people always had the option to hand-code so if they weren't doing that then it was because they figured out that, overall, it was better for them to use the visual tool. They knew they could hand-code and many of those people probably did as well - for different projects where they new they could get noticeably better speeds that way.

    One might say that those who currently use the tool will benefit as they will be forced to learn and code in this more efficient way but it seems to me that if the tool produces inefficient code then the answer is to fix the tool rather than bin it.

    No?

  14. dc77123

    code first after database first generation

    So, one question: You can have your database first, and generate from that... but then (using EF 7 and ASP.NET MVC) from THAT POINT ON (AFTER that initial generation) do you have to use code-first?

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like