Dapper
-
Slacker007 wrote:
Well, that is not really a good reason.
It's always been a good reason in the past. And I like living in the past.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
What do you use instead of Visual Studio?
The whole thing's rigged to blow, touch those tanks and "boooom"!
I use edlin to edit my code, and manually compile everything (yeah it takes a lot longer, but it's hella efficient code).
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
I use edlin to edit my code, and manually compile everything (yeah it takes a lot longer, but it's hella efficient code).
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
Wow, that looks like the hard way of doing things[^] :laugh: I guess you're paid by the hour? :laugh:
The whole thing's rigged to blow, touch those tanks and "boooom"!
Most things that are worth doing start out hard. And that's true for so many things in life. :)
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
Aren't .NET and Mono both from Microsoft, or are you targeting some other platform?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
I was just making a comment. I'm not targeting anything.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
Does anyone here use the Dapper ORM?
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
I have heard of Dapper, and that is about all. I have the most experience with EF but I am not going on the record to say that it is the best. I'm sure there are applications best suited for Dapper. I found this to be interesting. The conclusion at the end is the most important. Dapper looks to be faster in a lot of respects. Interesting. Don't Panic Labs – Speed Comparison: Dapper vs Entity Framework[^] Looks like Stackoverflow uses Dapper.
-
Dapper is written in C# which is from Microsoft too :-)
Regards, Nish
Website: www.voidnish.com Blog: voidnish.wordpress.com
He he - there is no escaping - is there?
-
Does anyone here use the Dapper ORM?
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013I've been using Dapper's spinoff NPoco for a couple of years in a large work project and it's worked out mostly great. The good: 1. Lightning fast, just a fraction slower than bare-bones ADO.NET. 2. No surprise SQL, you know exactly what SQL is sent to the server because you wrote it yourself (unless it's a simple single-table CRUD operation that NPoco generates itself). 3. Latest versions come with Linq expressions support. Back when our project got started there was no Linq support in NPoco and I ended up writing my own Linq-like repository wrapper. (I've made several other customizations to NPoco not all of which have made it into the official codebase, so I can't upgrade.) The bad: 1. No support for the JOIN syntax in NPoco's Linq implementation. Depending on how you look at it, this can be either a deficiency or a blessing (given how ugly SQL can get with auto-generated joins in EF and other full-feature ORMs). 2. The API can be a little confusing with too many overloaded methods and methods with different names but similar functionality.
-
Not that one, but I have used something called 'PetaPoco', which is kinda based on Dapper. The nice thing, to me, is it is a single .cs file that can be included right in you solution. He also has a later version that is a normal assembly. You will probably need to google 'PetaPoco' to find it.
NPoco is the latest version of PetaPoco and is still being actively maintained.
-
Dapper is considerably faster than EF. And I also believe that it was written BY Stackoverflow. GitHub - StackExchange/dapper-dot-net: Dapper - a simple object mapper for .Net[^]
andegre wrote:
BY Stackoverflow.
I see that. Interesting. Thanks for the info.
-
EF 6 has more optimizations than before, and is more powerful IMHO then 4 or 5. Any reason why you can't use that?
The biggest reason I use Dapper, sometimes I just want to create some POCOs and have them access the db. With Dapper all I need is a connection string and my classes..
-
Does anyone here use the Dapper ORM?
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013I used it for a project. I didn't use any of the object-relational mapping, but I liked that I could swap this:
SqlConnection conn = new SqlConnection(connString);
string sql = @"select * from MyTable";
SqlCommand cmd = new SqlCommand(sql, conn);
conn.Open();
SqlDataReader rdr = cmd.ExecuteReader(CommandBehavior.CloseConnection);
if (rdr.HasRows)
{
while (rdr.Read())
{
//do something with record
}
rdr.Close();
}with this:
SqlConnection conn = new SqlConnection(connString);
string sql = @"select * from MyTable";
IEnumerable flatResult = conn.Query(sql);I thought that was pretty handy, especially for quick prototyping where the table and field names were changing a lot and I didn't want to hassle with altering all the field names and just wanted a quick resultset back.
-
I used it for a project. I didn't use any of the object-relational mapping, but I liked that I could swap this:
SqlConnection conn = new SqlConnection(connString);
string sql = @"select * from MyTable";
SqlCommand cmd = new SqlCommand(sql, conn);
conn.Open();
SqlDataReader rdr = cmd.ExecuteReader(CommandBehavior.CloseConnection);
if (rdr.HasRows)
{
while (rdr.Read())
{
//do something with record
}
rdr.Close();
}with this:
SqlConnection conn = new SqlConnection(connString);
string sql = @"select * from MyTable";
IEnumerable flatResult = conn.Query(sql);I thought that was pretty handy, especially for quick prototyping where the table and field names were changing a lot and I didn't want to hassle with altering all the field names and just wanted a quick resultset back.
Inline SQL for anything (C# code files, etc.) is strongly discouraged at our shop, but I see your point. :)
