• 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!

C# Update

1.00 star(s)
So not more productive?

It depends on what you are doing.

Take for example (bad one) the ancient logging block. By the time you had installed it, configured it, referenced it, programmed to it's interface, figured out why it didn't work etc you were often better off rolling your own for what you actually needed rather than the subset of what it tried to offer.

When it so happens that what you want or need was exactly one of the scenarios envisaged then it may well help. It may also help (bizarrely) that having experimented and discovered it can't do what you want you don't need to go there again. Equally, if you know exactly what you want you may be able to bend your approach so it fits better.

So, overall, over time yes it can increase productivity. But, in a one off minor project it's doubtful. Though I dare say it won't be the last time I get proved wrong.
 
So not more productive?

It will help if you want to change from say SQL Server to Oracle but I gather that is unlikely to happen (note how most of the benefits relate to this).

I have used it in the past (not out of choice) and it just adds a database agnostic wrapper around ADO.NET, with a few helper methods for creating stored procedure commands etc.

IMO LinqToSQL is a better choice than Entity Framework (v 1.0 anyway) because it's more flexible / less annoying to use.
 
But Linq2SQL is dropped isn't it, not being developed any more?

Think about it... any giant library has some overhead. They shine on larger projects where the overhead gets averaged out, and the code is more consistent than 10 developers all doing the same thing their own way.
 
Linq2SQL gets my vote. Stupidly easy and quick, you can knock out a middlewear layer in about 5 minutes if you really wanted to.
 
Linq2Sql is not being developed any more, and Entity Framework is just as easy to use.

Updates to Linq To SQL in .NET 4.0 http://damieng.com/blog/2009/06/01/linq-to-sql-changes-in-net-40

I've found the main problem with EF (1.0) is that you can't use your own classes with it, you're forced down the route of auto-generated partial classes (very similar to typed datasets). This is a real pain when you want to use a validation framework or anything else which may need attributes on your entity properties. It can also go a bit "funny" if your DB schema changes.
 
Updates to Linq To SQL in .NET 4.0 http://damieng.com/blog/2009/06/01/linq-to-sql-changes-in-net-40

I've found the main problem with EF (1.0) is that you can't use your own classes with it, you're forced down the route of auto-generated partial classes (very similar to typed datasets). This is a real pain when you want to use a validation framework or anything else which may need attributes on your entity properties. It can also go a bit "funny" if your DB schema changes.

I think my statement still stands (although I suppose .net 4.0 hasn't been officially released yet)
 
Link2SQL support has been dropped which in theory means it is now redundant. It has been replaced by ADO.NET EF which will probably be dropped again in a year's time when MS realises that developers are going in for something else that is more powerful and feature rich.
 

Advertisers

Back
Top