CRUD operations in Entity Framework

[Solarion]

I have this three tier project put together, all very nice and I'm happy with it. I'm wanting to incorporate some EF into the crud operations. Can anyone suggest or post some examples please? Sample code of something you guys use in real life environments would be better!

 

[Solarion]

This is what I am currently using for my DAL. A data model which deals with the parameters.

Public Sub UpdateLog(ByVal supportInfo As SupportModel)

        Dim sqlParameters As SqlParameter() = New SqlParameter(3) {}

        sqlParameters(0) = New SqlParameter("@Id", SqlDbType.VarChar)
        sqlParameters(0).Value = supportInfo.Id
        sqlParameters(1) = New SqlParameter("@StartTime", SqlDbType.VarChar)
        sqlParameters(1).Value = supportInfo.StartTime
        sqlParameters(2) = New SqlParameter("@EndTime", SqlDbType.VarChar)
        sqlParameters(2).Value = supportInfo.EndTime
        sqlParameters(3) = New SqlParameter("@CallDate", SqlDbType.Date)
        sqlParameters(3).Value = supportInfo.CallDate

        conn.executeUpdateQuery(Scripts.UpdateLog, sqlParameters)

    End Sub

And the Database objects themselves in another class.

    Public Function executeUpdateQuery(ByVal _query As [String], ByVal sqlParameter As SqlParameter()) As Boolean
        Dim myCommand As New SqlCommand()
        Try
            myCommand.Connection = openConnection()
            myCommand.CommandType = CommandType.Text
            myCommand.CommandText = _query
            myCommand.Parameters.AddRange(sqlParameter)
            myAdapter.UpdateCommand = myCommand
            myCommand.ExecuteNonQuery()

        Catch e As SqlException
            Console.Write("Error - Connection.executeUpdateQuery - Query: " + _query + " " & vbLf & "Exception: " + e.StackTrace.ToString())
            Return False
        End Try

        Return True
    End Function

 

[DA-LION-619]

The EF haters are coming. Anyway looks like you're using SQL queries, why use EF if you're going to write SQL?

 

[Solarion]

The EF haters are coming. Anyway looks like you're using SQL queries, why use EF if you're going to write SQL?

So it's not necessary? I actually prefer SQL queries really. Just wanted really to get some opinions/advice like yours

 

[DA-LION-619]

So it's not necessary? I actually prefer SQL queries really. Just wanted really to get some opinions/advice like yours

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

The StackExchange/StackOverflow guys made and use this, so they eat their own dog food.

If you use Twitter, you should follow Nick, he posts screenshots of their code.

 

[Solarion]

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

The StackExchange/StackOverflow guys made and use this, so they eat their own dog food.

If you use Twitter, you should follow Nick, he posts screenshots of their code.

Will have a look at that, thanks.

 

[Beachless]

Just follow one of the many tutorials out there and then make sure you know how to make sure that the queries you end up with are efficient so that you dont also become a hater.

But if you want to write sql queries yourself just go with stored procedures.

 

[animal531]

If you're using EF then just use LINQ to create the CRUD, for example:

public List<Participant> GetParticipants()
{
    List<Participant> participants =
    (
        from t in entityContext.Participants
        select t
    ).ToList();

    return (participants);
}

LINQ is pretty easy to pick up, and looks a lot like SQL. Check out http://linqsamples.com/ for more info. If the above format is too big for you, then you can also use the more compressed lambda format.
The only crappy thing here is that you have to create all the CRUD for each table, or otherwise use a generator.

Dapper for example makes that easier, since it already has a lot of generics built in, so you just run a generic Select/Query and it automaps it to your table for you. If you're writing a new project then check it out, it's pretty nifty.

 

[halfmoonforever]

+1 for Dapper, really lightweight and does what it says on the box, especially combined with an MVC project, much more straightforward and easy to use than EF.

If your project is working and everything is nice, why change to EF or any ORM for that matter?

 

[Solarion]

+1 for Dapper, really lightweight and does what it says on the box, especially combined with an MVC project, much more straightforward and easy to use than EF.

If your project is working and everything is nice, why change to EF or any ORM for that matter?

Yup I've scrapped the idea. I'll tinker around with EF as a side project but I am happy with the way things are and it has brought my project time spent down dramatically using the model I have now (plenty of re-usability and generic structure) so why change it.