Please post your helpful functions (C# or VB.Net)

For the n00bs, when writing a polling function use the Timer class in System.Threading with the callback instead of the Timer class that raises events, especially if only one polling operation may run at a time.

Code: 
public MyPoller()
{
    _timer = new Timer(DoPoll, null, Timeout.Infinite, Timeout.Infinite);
    _isPolling = false;
}

void Start()
{
    _timer.Change(0, TimeSpan.FromSeconds(5));
}

void Stop()
{
    _timer.Change(Timeout.Infinite, Timeout.Infinite);
}

void DoPoll(object state)
{
    if(_isBusy)
        return;

    _isBusy = true;

    try
    {
        // do stuff
    }
    finally
    {
        _isBusy = false;
    }
}

Of course you'll need to make sure you dispose that _timer object.
 
Kilgore_Trout_Redux said:
Please never use a select *. Always fully qualify the columns you are selecting.
Click to expand...

This is true. And while we are at it, NEVER do this:

Code: 
string sql = "select firstname, lastname from people where id = " + 13;

Use SqlParameters or in Dapper's case

Code: 
string sql = "select firstname, lastname from people where id = @id";
var param = new {id = 13};
var people = conn.Query<Person>(sql, param);

Personally I'd use a stored proc rather than code SQL in code but that's another discussion/holy war.
 
The code you have written here really isn't suitable for a professional production environment. You show a severe lack of understanding of what it takes to write decent code.
Click to expand...

Agreed, guy is only 3 months into C# though. He needs proper guidance from his team mates (doesn't look like that is happening since he is junior) and more importantly, a book to read before fscking around with code.

using(var conn = GetConnection())
{
}
Click to expand...

@Beer

This. Use a "using" command rather.
 
CamiKaze said:
Agreed, guy is only 3 months into C# though...
Click to expand...

Didn't know he is that junior or I wouldn't have been that harsh.

I do hope he takes the advice of focusing on good practices rather than just churning out code.

I would advise against frameworks like dapper at the moment as they abstract too much. For now he needs to learn about how things work under the hood. Coding against interfaces, etc. I am guessing he doesn't understand generics either so he needs to figure those out before using them as well.

Once he can write clean, well structured code he can start looking at how to make his life easier.
 
Last edited:
Hamster said:
That's a very MS fanboy thing to say

Compared to NHibernate though I'm with you :sick:
Click to expand...
I am an MS fanboy. No qualms there.
I live a good life because of MS. Also use Java and Linux here and there, so not a loyalist. I use the best tools suited to the job at at hand. Thankfully MS comes to the party most of the time.

I have used Subsonic (early days), then nHibernate, then EF. Between Subsonic and nHibernate I gave EF a go, but still too early days. Started using EF at version 5 as it was now considered enterprise ready. Been happy ever since.

nHibernate was a real pain the @ss to use. OMG.
 
Mike Smit said:
I am an MS fanboy. No qualms there.
I live a good life because of MS. Also use Java and Linux here and there, so not a loyalist. I use the best tools suited to the job at at hand. Thankfully MS comes to the party most of the time.

I have used Subsonic (early days), then nHibernate, then EF. Between Subsonic and nHibernate I gave EF a go, but still too early days. Started using EF at version 5 as it was now considered enterprise ready. Been happy ever since.

nHibernate was a real pain the @ss to use. OMG.
Click to expand...

I'd be a hypocrite if I didn't admit a bit of MS fanboyism on my part. Never used EF for any real work. Dapper has made things so much easier for me (full control and I don't have to worry about mapping results to models). To the developer it is basically two extra extension methods added to the IDbConnection. To me this is what MS should have built in to .NET and what an "ORM" should be - unobtrusive, easy to use and ****ing fast!

And don't get me started on nHibernate....so much pain and time wasted.
 
Hamster said:
Code: 
string sql = "select firstname, lastname from people where id = @id";
var param = new {id = 13};
var people = conn.Query<Person>(sql, param);
Click to expand...

Nice and clean.

What's the syntax for persist?
 
Hamster said:
I'd be a hypocrite if I didn't admit a bit of MS fanboyism on my part. Never used EF for any real work. Dapper has made things so much easier for me (full control and I don't have to worry about mapping results to models). To the developer it is basically two extra extension methods added to the IDbConnection. To me this is what MS should have built in to .NET and what an "ORM" should be - unobtrusive, easy to use and ****ing fast!

And don't get me started on nHibernate....so much pain and time wasted.
Click to expand...

Does Dapper do Code First? If so, I will check it out in the AM. I assume so because you suggest you don't do result to model mapping (sounds like code first in EF which is how I do it).
All tech is worth a look to see if it fits a purpose.
 
_kabal_ said:
Nice and clean.

What's the syntax for persist?
Click to expand...
Code: 
conn.Execute(sql, param);
// or
conn.Execute(procName, param, commandType: CommandType.StoredProcedure);

It'll return the number of rows affected.
 
Mike Smit said:
Does Dapper do Code First? If so, I will check it out in the AM. I assume so because you suggest you don't do result to model mapping (sounds like code first in EF which is how I do it).
All tech is worth a look to see if it fits a purpose.
Click to expand...
If by code first you mean setting up your schema through cs models - I doubt it. I've never been a fan of doing that anyway. Databases and database access can very easily become a bottleneck so I prefer having the queries and schema done as a separate task which DBAs can vet if need be. Maybe I'm over cautious or "old school".
 
Hamster said:
If by code first you mean setting up your schema through cs models - I doubt it. I've never been a fan of doing that anyway. Databases and database access can very easily become a bottleneck so I prefer having the queries and schema done as a separate task which DBAs can vet if need be. Maybe I'm over cautious or "old school".
Click to expand...
It's actually really cool and you have complete control over the schema via migration files that you generate when you make model changes (and yes - you understood it correct).
You develop the model with your business logic in mind, and not the DB. When you generate the migration files, EF auto generates the correct relationships and indexes based on the model design. You can tweak it further if you like. You can also generate migration files without a model change to have sprocs, additional indexes, etc.. pushed to the DB.
Best of all - automatically got schema version control. Can roll back and forth to different points as you wish.
Best best of all... Strongly typed.

After a new version deployment, the schema of the DB is auto updated to match the latest version of the software. Deployment to multiple sites on different versions is a piss easy exercise this way.

But Ye - stokes for folks. I feel like I have complete control from model to DB, the model fits the business logic perfectly, and this works well for me.

Had a look at Dapper. It has some pretty impressive execution times. Going to have a fiddle when I get a gap as I can see some good uses for it.
 
Mike Smit said:
It's actually really cool and you have complete control over the schema via migration files that you generate when you make model changes (and yes - you understood it correct).
You develop the model with your business logic in mind, and not the DB. When you generate the migration files, EF auto generates the correct relationships and indexes based on the model design. You can tweak it further if you like. You can also generate migration files without a model change to have sprocs, additional indexes, etc.. pushed to the DB.
Best of all - automatically got schema version control. Can roll back and forth to different points as you wish.
Best best of all... Strongly typed.

After a new version deployment, the schema of the DB is auto updated to match the latest version of the software. Deployment to multiple sites on different versions is a piss easy exercise this way.

But Ye - stokes for folks. I feel like I have complete control from model to DB, the model fits the business logic perfectly, and this works well for me.

Had a look at Dapper. It has some pretty impressive execution times. Going to have a fiddle when I get a gap as I can see some good uses for it.
Click to expand...
Hmmm, maybe it requires a revisit. Not sure how it will fit in with databases with 100s of tables and procs (welcome to the banking jungle), but for smaller projects it might well be worth it if you use it from the start. There are VS DB Projects one can use to version schemas and rollback to specific versions etc. that produces a pack file you can execute against SQL Server (Yet to see it used successfully and continuously...but I'm hoping)

It is an interesting discussion (maybe not for this thread) but splitting your schemas and code into separate repositories have benefits like stricter control (pull request, write permissions etc) on your db repo so you can protect it at all cost, especially if you work in a large team or with a lot of people that "don't put enough emphasis on quality" ;)
 
Last edited:
EF 6 has the ability to map stored procs to strongly typed objects. If you use EF well, you can get good performance by incorporating Entity.Extentions which gives you the ability to cache queries and execute future queries. I've used future queries with good success.

Another awesome lightweight framework is ORMLite from Service Stack. Have a look at V3 since V4 is commercial. A lot more power than Dapper with just as good read speeds.
 
Hamster said:
Hmmm, maybe it requires a revisit. Not sure how it will fit in with databases with 100s of tables and procs (welcome to the banking jungle), but for smaller projects it might well be worth it if you use it from the start. There are VS DB Projects one can use to version schemas and rollback to specific versions etc. that produces a pack file you can execute against SQL Server (Yet to see it used successfully and continuously...but I'm hoping)

It is an interesting discussion (maybe not for this thread) but splitting your schemas and code into separate repositories have benefits like stricter control (pull request, write permissions etc) on your db repo so you can protect it at all cost, especially if you work in a large team or with a lot of people that "don't put enough emphasis on quality" ;)
Click to expand...

shauntir said:
EF 6 has the ability to map stored procs to strongly typed objects. If you use EF well, you can get good performance by incorporating Entity.Extentions which gives you the ability to cache queries and execute future queries. I've used future queries with good success.

Another awesome lightweight framework is ORMLite from Service Stack. Have a look at V3 since V4 is commercial. A lot more power than Dapper with just as good read speeds.
Click to expand...

I see a need for a dedicated ORM thread. Some nice stuff coming out here.
 
Taken a bit of a roasting in this thread, but I'm a tough old dog. Thanks for being honest guys and big thanks for the advice ;). Seems I have some catching up to do with this C# but that's good, it would be boring if I knew it all :D
 
Mike Smit said:
Does Dapper do Code First? If so, I will check it out in the AM. I assume so because you suggest you don't do result to model mapping (sounds like code first in EF which is how I do it).
All tech is worth a look to see if it fits a purpose.
Click to expand...

No, Dapper is a micro or lightweight ORM it doesn't have functionality like code first but to make up for it, it's fast. It was written by the StackOverflow devs to replace what they were using, iirc EF.
 
Been using Dapper for all my projects. As mentioned, not bloated. I also use Dapper.Mapper to
Just write
Code: 
var lst = conn.Query<class1,class2,class3,....... until 7th>(
                             proc,
                             splitOn: "JoinColumn1,JoinColumn2,JoinColumn3,......",
                             commandType: CommandType.StoredProcedure).ToList();
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X