Reply to: C# Update

[fullyautomatix]

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.

[jmo21]

Updates to Linq To SQL in .NET 4.0 http://damieng.com/blog/2009/06/01/l...nges-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)

[Jaws]

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/l...nges-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.

[jmo21]

Linq2Sql is not being developed any more, and Entity Framework is just as easy to use.

[Weltchy]

Linq2SQL gets my vote. Stupidly easy and quick, you can knock out a middlewear layer in about 5 minutes if you really wanted to.

[d000hg]

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.

[Jaws]

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.

[ASB]

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.

[d000hg]

It depends. It takes a few minutes to write code to pull data from a query into your object. For each query. If you use a framework, it is less setup per query, but a much bigger overhead getting the thing set up in the first place.

Spring is the same... writing a single JSP page and a servlet is way faster than setting up all your beans and things, but when you have 100 pages it can go the other way.

Also, development speed is not the biggest thing about such frameworks.

[suityou01]

Yes. No, Yes.

So not more productive?

The Data Access Application Block provides the following benefits:

* It uses the functionality provided by ADO.NET 2.0 and with it, you can use ADO.NET functionality along with the application block's functionality.
* It reduces the need to write boilerplate code to perform standard tasks.
* It helps maintain consistent data access practices, both within an application and across the enterprise.
* It reduces difficulties in changing the database type.
* It relieves developers from learning different programming models for different types of databases.
* It reduces the amount of code that developers must write when they port applications to different types of databases.

[ASB]

Enterprise library is supposed to make things easier is it not? Would this not make me more productive, AND learn stuff?

Yes. No, Yes.

[HairyArsedBloke]

Ops, sorry. I misread your post. S#arp isn't gonna help for a desktop app.

[suityou01]

So it's a desktop app talking to a DB? If it's a small project I'd not bother with all that middleware stuff... if it just has to work. A little desktop app shouldn't get ideas above its station, to be all Enterprisey.

If it's bigger then the story may change somewhat. Do you want to appear productive, or find a way to drag it out and learn stuff?

Enterprise library is supposed to make things easier is it not? Would this not make me more productive, AND learn stuff?

[d000hg]

So it's a desktop app talking to a DB? If it's a small project I'd not bother with all that middleware stuff... if it just has to work. A little desktop app shouldn't get ideas above its station, to be all Enterprisey.

If it's bigger then the story may change somewhat. Do you want to appear productive, or find a way to drag it out and learn stuff?

[suityou01]

I'm probably the last person to give techie advice, but I've been trying out S#arp Architecture on a project. MVC/NHib/SQL etc. I'm using the Telerick opensource MVC JQuery thingies too.

ooh toys

The last thing I touched was Enterprise Library 4.1. Had some good stuff in there, nullable objects, serialisable thingies. Lots of cool stuff.

Will take a peek at the aforementioned, thanks.