• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

Is .NET Entity Framework still cool?

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    Is .NET Entity Framework still cool?

    I seem to go through periods of using C# actively every couple of years. Typically that means that while the language may have moved on a bit, a whole new database access framework has become de rigueur.

    I think last time I was quite keen on EF but has it since fallen from favour? My DB needs are quite modest, by main query is whether to wrap all DB access in stored procedures as was deemed best practice at times, or just use EF which (sort of) achieves the same goal.

    What do you C# monkeys do these days for standard SQL DB access, those of you who haven't all moved to Big Data and NoSQL gravy trains at least? My use case is predominantly to store received data from a 3rd party.
    Originally posted by MaryPoppins
    I'd still not breastfeed a nazi
    Originally posted by vetran
    Urine is quite nourishing

    #2
    Originally posted by d000hg View Post
    I seem to go through periods of using C# actively every couple of years. Typically that means that while the language may have moved on a bit, a whole new database access framework has become de rigueur.

    I think last time I was quite keen on EF but has it since fallen from favour? My DB needs are quite modest, by main query is whether to wrap all DB access in stored procedures as was deemed best practice at times, or just use EF which (sort of) achieves the same goal.

    What do you C# monkeys do these days for standard SQL DB access, those of you who haven't all moved to Big Data and NoSQL gravy trains at least? My use case is predominantly to store received data from a 3rd party.
    I moved away from EF a while ago, too many issues. But if you are comfortable with it and have modest needs stick with it.

    I tend to use a micro-orm called Dapper, it meets all my needs, simple and fast. You can use it with stored procs if you want but I tend to use inline sql along with Dapper.Contrib which makes it even easier. For example

    var id = await cn.InsertAsync(customer);

    Get it here.
    GitHub - StackExchange/Dapper: Dapper - a simple object mapper for .Net


    For what it's worth, I tend to stick with a repository pattern (has it's faults) but it's simple. I like simple.

    Comment


      #3
      Does nHibernate get used much in the .NET market?

      Comment


        #4
        Originally posted by minestrone View Post
        Does nHibernate get used much in the .NET market?
        Not sure, never used it and would probably ignore contracts asking for it.

        Comment


          #5
          I use EF for one of the systems that I sell commercially. It's a bit heavyweight for my needs and to be honest, I wish I had gone with Dapper instead but I'm way too lazy to refactor it and it works, so...

          Check out Dapper first - it does what the majority of people need quite nicely, and it's much more lightweight than EF.

          Never used nHibernate. I use hibernate for java projects, but not for .NET. No idea why actually.

          Comment


            #6
            Another alternative, slightly above Dapper (no magic strings), but less heavyweight than EF (no object state tracking).

            Supports lots of different databases, including SQL Server, Oracle, SQLite, DB2, MySql etc

            GitHub - linq2db/linq2db: Linq to database provider.

            Comment


              #7
              Originally posted by DimPrawn View Post
              Another alternative, slightly above Dapper (no magic strings), but less heavyweight than EF (no object state tracking).

              Supports lots of different databases, including SQL Server, Oracle, SQLite, DB2, MySql etc

              GitHub - linq2db/linq2db: Linq to database provider.
              Is that the old LINQ MS did for DB, then backtracked on when LINQ was new and cool, or totally different?

              Sent from my ONEPLUS A6003 using Tapatalk
              Originally posted by MaryPoppins
              I'd still not breastfeed a nazi
              Originally posted by vetran
              Urine is quite nourishing

              Comment


                #8
                Originally posted by d000hg View Post
                Is that the old LINQ MS did for DB, then backtracked on when LINQ was new and cool, or totally different?

                Sent from my ONEPLUS A6003 using Tapatalk
                Totally different in that this works with a whole bunch of databases (the MS Linq to SQL only worked with MS SQL Server).

                But is of the same philosophy in that it provides Linq to database SQL generation. Unlike Dapper where you end up with embedded SQL strings all over the place.

                Comment


                  #9
                  Originally posted by DimPrawn View Post
                  Totally different in that this works with a whole bunch of databases (the MS Linq to SQL only worked with MS SQL Server).

                  But is of the same philosophy in that it provides Linq to database SQL generation. Unlike Dapper where you end up with embedded SQL strings all over the place.
                  Never found it an issue with embedded sql, you tend to organise the repositories so they make sense. 80% of your work is simple update/insert/delete/fetch and you can use contrib so this basic sql is done for you.

                  It's one of those if you can write decent sql and can organise a piss up in brewery you can successfully use Dapper or most other micro-orms.

                  Dapper does have it's limitations, same for repository pattern but this crap about magic strings is nonsense.

                  Comment


                    #10
                    Originally posted by woohoo View Post
                    Never found it an issue with embedded sql, you tend to organise the repositories so they make sense. 80% of your work is simple update/insert/delete/fetch and you can use contrib so this basic sql is done for you.

                    It's one of those if you can write decent sql and can organise a piss up in brewery you can successfully use Dapper or most other micro-orms.

                    Dapper does have it's limitations, same for repository pattern but this crap about magic strings is nonsense.
                    You don't know what you are talking about bro.

                    Comment

                    Working...
                    X